Který port používá DNS? Port 53, a kdy ne

Jaký port DNS používá pro běžné vyhledání?

Normální dotaz, ten druh, který váš prohlížeč posílá desítky za minutu, jde ven jako jeden paket UDP na port 53 a stejnou cestou se vrací zpátky. RFC 1035 nazývá UDP "doporučenou metodou pro standardní dotazy na internetu", protože nepotřebuje žádný handshake: jeden paket ven, jeden zpátky, hotovo. To je i důvod, proč DNS působí okamžitě, když funguje, a proč stačí jeden zahozený paket, aby to vypadalo rozbité, protože UDP za vás automaticky neopakuje. Resolver software na vašem zařízení nebo routeru řeší opakování sám, obvykle proti druhému nakonfigurovanému serveru, pokud ten první mlčí.

Kdy DNS místo toho použije TCP?

Dvě situace tlačí výměnu DNS na TCP port 53. První je přenos zóny, kdy si sekundární jmenný server stahuje kompletní kopii zóny z primárního. RFC 1035 výslovně uvádí, že "UDP není přijatelné pro přenosy zón", protože operace potřebuje spolehlivý, seřazený proud, ne jeden paket na nejlepší úsilí. Druhá je odpověď, která se nevejde do aktuálně používané velikosti zprávy UDP. Když se to stane, server pošle zpátky zkrácený paket UDP s nastaveným bitem TC (truncated), a kompatibilní resolver si bitu všimne a stejný dotaz znovu pošle přes TCP, aby dostal úplnou odpověď. Toto chování si můžete vynutit sami a přímo vidět úplnou odpověď:

dig +tcp example.com

Běžné dotazy tuto cestu potřebují zřídka, ale existuje přesně proto, aby DNS fungovalo dál, i když odpověď přeroste to, co se vejde do jednoho paketu UDP, což se dnes děje častěji než dřív.

Co byl limit 512 bajtů a co ho změnilo?

RFC 1035 stanovilo velikost zprávy UDP na 512 bajtů, včetně hlavičky, bez počítání hlaviček IP nebo UDP samotných. To číslo bylo v roce 1987 štědré, kdy odpověď DNS byla hrstka adresních záznamů. Přestalo být štědré ve chvíli, kdy se podpisy DNSSEC, delší názvy hostitelů a záznamy s mnoha IP adresami staly běžnými, protože podepsaná odpověď se záznamem RRSIG běžně sama o sobě přeroste 512 bajtů.

RFC 6891, publikované v roce 2013, opravilo tento strop, aniž by se dotklo samotného protokolu na drátě: EDNS0 přidává pseudozáznam OPT, který resolveru umožní oznámit "největší UDP payload, který lze znovu sestavit a doručit v síťovém zásobníku dotazujícího", a RFC navrhuje jako praktický výchozí bod 4096 bajtů. Resolver a server, které oba podporují EDNS0, si mohou přes jeden paket UDP vyměnit odpovědi několikanásobně větší než starý strop 512 bajtů a na TCP přejít, jen když ani tato větší tolerance nestačí. Téměř každý resolver dnes v provozu, včetně toho ve vašem operačním systému, mluví EDNS0 ve výchozím stavu, takže tento upgrade se odehrál sám, bez jakékoli akce z vaší strany.

Proč firewally, které povolují jen UDP 53, dělají skutečné problémy

Pravidlo firewallu napsané před lety a nikdy pak nepřezkoumané často zní "povolit UDP port 53, zamítnout všechno ostatní související s DNS". Toto pravidlo blokuje záložní přechod na TCP, který protokol potřebuje, a chyba, kterou vyvolá, se špatně diagnostikuje, protože většina vyhledání pořád funguje normálně. Selhávají jen ta, která přerostou limit UDP, a selhávají způsobem, který vypadá náhodně: doména se většinu času přeloží normálně a pak vyprší časový limit, obzvlášť jakmile je zapojena validace DNSSEC, protože validující resolver musí spolu s odpovědí, na kterou se ptal, stáhnout i záznamy RRSIG a DNSKEY.

Praktickým výsledkem je, že zóny podepsané DNSSEC a jakákoli sada záznamů s mnoha hodnotami (třeba doména s tuctem poštovních serverů) se za firewallem povolujícím jen UDP stanou nespolehlivými, zatímco všechno ostatní vypadá zdravě. Blokování odchozího TCP 53, nebo jeho blokování jen v jednom směru, je jedním z běžnějších vlastnoručně způsobených výpadků DNS a málokdy se to projeví v základní kontrole konektivity, protože ta obvykle zkouší jen UDP.

DNS over TLS a DNS over HTTPS: jiné porty, stejná vyhledání

Dva novější transporty přenášejí stejné dotazy a odpovědi DNS, ale úplně mimo port 53. DNS over TLS, definované v RFC 7858, obalí každý dotaz do relace TLS na TCP portu 853, zvoleného tak, aby síťový operátor pořád viděl, že se DoT děje (a mohl ho zablokovat), i bez dešifrování, protože samotný port je jasný signál.

DNS over HTTPS, definované v RFC 8484, jde ještě dál. Posílá dotazy DNS jako obyčejné požadavky HTTPS na portu 443, stejném portu jako každý jiný web, který navštívíte, a RFC uvádí jako záměrnou vlastnost "schopnost míchat provoz DoH s ostatním provozem HTTPS na stejném spojení". To je celá podstata DoH: síť, která filtruje jen podle portu, nedokáže oddělit vyhledání DNS od jakéhokoli jiného požadavku HTTPS, protože jde o stejný protokol na stejném portu. Chrome, Firefox i Edge dnes umí posílat DNS tímto způsobem ve výchozím stavu, což je důvod, proč blokování "portu 53" v síti už negarantuje, že jste zablokovali DNS. Garantuje, že jste zablokovali klasický transport; prohlížeč se zapnutým DoH pokračuje v překladu jmen přes 443 bez ohledu na to.

Co je mDNS na portu 5353?

Multicast DNS je jiný protokol s podobným jménem. RFC 6762 ho definuje jako zařízení "posílající zprávy dotazu a odpovědi podobné DNS přes IP multicast na UDP port 5353", adresované multicastové skupině 224.0.0.251 (nebo jejímu ekvivalentu v IPv6, FF02::FB) místo konkrétnímu serveru. Není zapojen žádný centrální jmenný server: každé zařízení v segmentu lokální sítě poslouchá na portu 5353 a odpovídá za vlastní jméno. Takto se tiskárna nebo chytrý reproduktor stane dostupným jako device.local, aniž by kdokoli pro něj konfiguroval DNS záznam. Je záměrně omezené na lokální spoj a s rozlišováním veřejného doménového jména nemá nic společného, takže provoz mDNS nikdy nepotřebuje opustit váš router.

Jak otestovat, zda je port 53 dostupný

Začněte přímým dotazem proti známě funkčnímu resolveru, který vám řekne, jestli běžná vyhledávání UDP fungují vůbec:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Pokud to uspěje, ale máte podezření, že je zablokovaná záložní cesta TCP, vynuťte TCP a porovnejte:

dig +tcp example.com @1.1.1.1

Dotaz UDP, který uspěje, zatímco verze s vynuceným TCP vyprší, je silným signálem, že něco mezi vámi a resolverem zahazuje konkrétně TCP 53, přesně ten druh selhání popsaný výše. Pro testování syrové dostupnosti portu mimo vaši vlastní síť je užitečný náš nástroj pro kontrolu portu: namiřte ho na port 53 vašeho resolveru nebo jmenného serveru a otevře skutečné spojení TCP z jiné sítě, čímž potvrdí, zda je TCP 53 vůbec dostupný. Výsledek čtěte s jednou výhradou: kontrola portu testuje TCP, takže úspěch tam potvrdí, že záložní cesta je otevřená, ale nic neříká o UDP, které nemá handshake ke stejnému otestování. Pro samotný dotaz, včetně porovnání odpovědí z více veřejných resolverů a různých regionů najednou, spusťte nástroj pro DNS dotaz.

Časté otázky

Musím otevřít TCP 53 vedle UDP 53?

Ano, pro odchozí provoz k resolveru. Firewall, který povoluje jen UDP 53, zvládne většinu dotazů v pořádku a pak nepředvídatelně selže na větších, typicky podepsaných DNSSEC odpovědích, které potřebují záložní TCP.

Zastaví blokování portu 53 veškerý provoz DNS?

Už ne. Zablokuje klasický transport UDP/TCP. DNS over HTTPS běží na portu 443 a vypadá jako jakýkoli jiný požadavek HTTPS a DNS over TLS běží na vlastním portu 853, takže prohlížeč nebo aplikace se zapnutým jedním nebo druhým pokračuje v překladu jmen.

Je DNS over HTTPS stejný protokol jako běžné DNS?

Dotazy a odpovědi jsou stejné DNS záznamy a kódy definované RFC 1035. Mění se jen transport: místo syrového paketu UDP nebo TCP na portu 53 je stejný požadavek zabalený uvnitř požadavku HTTPS na portu 443.

Proč dig někdy použije TCP, aniž by byl instruován?

Když se odpověď UDP vrátí zkrácená, s nastaveným bitem TC, standardně kompatibilní klient automaticky znovu pošle dotaz přes TCP, aby dostal úplnou odpověď. Nejčastěji to uvidíte u domén se zapnutým DNSSEC nebo s mnoha záznamy stejného typu.

Je mDNS na portu 5353 totéž jako DNS mého poskytovatele internetu?

Ne. mDNS funguje jen v segmentu vaší lokální sítě, nemá centrální server a rozlišuje jména jako device.local pro zařízení na stejném spoji. Nemá žádnou roli v rozlišování veřejné domény jako example.com.

Jaká je normální velikost payloadu EDNS0 dnes?

RFC 6891 navrhuje jako praktickou výchozí hodnotu 4096 bajtů a většina současných resolverů oznamuje něco v tomto rozsahu, daleko nad původním stropem 512 bajtů, než přejde na TCP jen tehdy, když ani to nestačí.