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/