Žádný TLD. První v řadě jsou tzv root servery, který dodají adresy DNS serverů pro TLD. Těchto serverů je 13 - mají 13 adres, ale jinak jsou to tisíce serverů po světě. Seznam root serverů se musí vlastnímu DNS dodat, respektive jsou snad vždy přímo ve výchozí konfiguraci. Pokud se něco změní (což není zase tak časté), je třeba tento seznam aktualizovat (manuálně nebo automaticky).
Huh?
8.8.8.8 je „normální“ rekurzor. Takový získáš i když si nainstaluješ třeba bind (asi je potřeba ručně povolit, aby rekurzoroval i lidem z venku).
Bohužel mít to otevřené jen tak do netu není úplně nejlepší, protože spousta lidí začala otevřené rekurzory zneužívat k DDoS útokům (není mi jasné, proč nezneužívají (i) autoritativní servery, obzvláště v době DNSSEC není problém vyrazit z každého druhého autoritativního serveru dlouhou odpověď).
Neexistuje žádný „seznam domén“. DNS je hierarchické, takže když se chci zeptat na adresu www.example.com
, zeptám se na tu adresu serveru obsluhujícího doménu example.com
. Ten také neznám, takže se zeptám serveru obsluhujícího doménu com
, který server má na starosti example.com
. Server obsluhující doménu com
také neznám, takže se zeptám nějakého kořenového DNS serveru (resp. serveru pro kařenovou doménu). Každý plnohodnotný DNS resolver (např. ten 8.8.8.8) musí znát nějaký kořenový server, ideální je, když má jejich úplný seznam. Od kořenových serverů už se pak doptá k libovolnému názvu. O kořenových serverech se dočtete třeba na Wikipedii, včetně jejich aktuálního seznamu a odkazu na autoritativní seznam kořenových serverů.
Když jsem kdysi v 90. letech začínal s DNS, _dlouho_ jsem se domníval, že "iterativní" dotazování probíhá přesně tak, jak je uvedeno na druhém obrázku(minimalizace dotazů). Pořád mně tam něco nesedělo a tak jsem po určité době přišel na to, kde je pravda... Ale nechápal jsem, proč původní návrháři zvolili to "standardní", ne moc elegantní, řešení.
To, že je moje původní myšlenka dnes již standardizována mě samozřejmě potěšilo :-)))
Dá se jen předpokládat, že to je dáno tím, že první verze DNS byla vytvořena v roce 1983, ještě v ARPANETu, dávno před internetem. A jak to tak bývá, nároky se časem změnily, ale základ zůstal. Původně prostě neběžel DNS server na každé kravině a bylo pravděpodobné, že se ke správné hodnotě dostaneš dříve, než se prokoušeš celým názvem. Ušetřilo to značnou část režie a v době, kdy se rychlosti počítaly v jednotkách, maximálně desítkách kilobitů a to ještě za dobrého větru, to bylo výhodnější, než se jednoho a toho samého serveru ptát postupně třikrát jen proto, abych nakonec zjistil, že se stačilo zeptat jednou, maximálně dvakrát. Co se týká bezpečnosti, internet vznikl jako médium pro sdílení, ne pro utajování, takže nebyl důvod tento archaický a funkční systém nějak měnit. Ostatně, internet je (respektive donedávna byl) plný zajímavostí, které z bezpečnostního hlediska nedávají smysl a které se v posledních pár letech "lepí" různými rozšířeními. Krásným příkladem je třeba SMTP, což je ještě mnohem horší, než "děravé" DNS. Bohužel, ačkoliv by bylo spoustu věcí třeba předělat od základů, nelze jen tak ze dne na den něco utnout a spustit něco nového, viz IPv6.
Původně se počítalo, že DNS půjde víc do hloubky (dnes se rozšiřuje hlavně do šířky). Třeba typická adresa v univerzitním prostředí - zarizeni.katedra.fakulta.univerzita.edu.stat. Nemusí mít každá katedra svůj DNS server, pokud bude na úrovni fakulty nebo univerzity, ušetří se jeden nebo dva dotazy. Zároveň býval sloučený do jednoho serveru autoritativní server i resolver. Takže ve výše uvedeném případě, i kdyby DNS server měla každá fakulta, univerzitní server by mohl mít daný záznam nakešovaný a odpovědět jím rovnou.
Mne naopak překvapilo, že každá zóna musí mít svůj server. DJBDNS v konfiguraci běžně zóny „přeskakuje“, je zvykem třeba jmenné servery pojmenovávat a.ns.example.com
, b.ns.example.com
atd., přičemž zónu ns.example.com
nikde nedefinujete. Vždycky jsem si myslel, že ta zóna není potřeba, právě proto že se v dotazu posílá vždy celé jméno. Nevím, zda DJBDNS ten SOA záznam pro doménu ns.example.com
syntetizuje, nebo jestli porušuje RFC a s minimalizací nebude fungovat. Ostatně do zónového souboru, který používají jiné servery, je také možné napsat jména s tečkou. Jsem zvědav, jak ta minimalizace bude fungovat v praxi.
Každá zóna rozhodně nemusí mít svůj server. Krásně je to vidět třeba na reverzních IPv6 záznamech, kde rozhodně není samostatný server co každá tečka ve jméně. Pokud se zeptáte na neúplné jméno, dostanete takzvaný Empty Non-Terminal, tedy návratový kód NOERROR
a žádná data:
$ dig 0.0.0.8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa ns @ns.iinfo.cz ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2452 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 … ;; QUESTION SECTION: ;0.0.0.8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa. IN NS ;; AUTHORITY SECTION: 8.6.0.0.c.7.6.0.1.0.0.2.ip6.arpa. 3600 IN SOA ns.iinfo.cz. hostmaster.adminit.cz. 2015090701 21600 7200 2419200 3600
Unbound obsahuje optimalizaci, že pro reverzní IPv6 záznamy skáče po osmi labelech. Větší problém je, že spousta autoritativních DNS serverů se nechová v souladu se standardy a odpovídá návratovým kódem NXDOMAIN
v případě dotazu na ENT. Příkladem je třeba tato zóna:
$ host wildcard.whitehouse.gov.edgekey.net wildcard.whitehouse.gov.edgekey.net is an alias for wwws.eop-edge-lb.akadns.net. wwws.eop-edge-lb.akadns.net is an alias for e4036.dscb.akamaiedge.net. e4036.dscb.akamaiedge.net has address 104.103.75.94 e4036.dscb.akamaiedge.net has IPv6 address 2a02:26f0:11a:19f::fc4 e4036.dscb.akamaiedge.net has IPv6 address 2a02:26f0:11a:195::fc4 $ host whitehouse.gov.edgekey.net Host whitehouse.gov.edgekey.net not found: 3(NXDOMAIN)
Protože kód NXDOMAIN
říká, že dané jméno neexistuje a neexistuje celý podstrom končící na dotazované jméno, je takové chování vcelku nebezpečné, protože položí-li někdo neúplný dotaz, otráví cache rekurzivního serveru, který přestane odpovídat i na poddotazy. Minimalizace dotazovaného jména tuto vadu autoritativních serverů exploituje ve velkém. Proto Unbound obsahuje úpravu proti standardu, kdy vypíná minimalizaci dotazovaného jména při návratovém kódu jiném než NOERROR
. To také dává aktivním útočníkům návod, jako minimalizaci eliminovat ;)
Více informací k Unboundu zde: https://ripe72.ripe.net/archives/video/219/