Princip DNS
Jak tedy systém DNS pracuje? Obecně se na celý systém DNS dá pohlížet jako na decentralizovanou hierarchickou databázi, jejíž hlavní smysl je poskytovat informace nutné pro překlad jmen na IP adresy. Informace uložené v DNS se ukládají ve formě, která se nazývá Resource Record (dále též RR záznam). Protože data uložená v RR záznamech jsou spíše statického charakteru, mají samotné informace i specifikaci maximální doby platnosti záznamu, tzv. TTL (Time to Live). Celá struktura jednoho RR záznamu obsahuje vlastníka (owner), třídu (class), typ (type), ttl a data (rdata – resource data). Třídy byly v návrhu specifikovány dvě: IN – pro Internet, a CH – pro Chaos. Třída Chaos byla vytvořena pro experimentální účely a v praxi se s ní můžete potkat pouze při speciálním typu dotazu na verzi DNS serveru (CH TXT version.bind.). Mezi základní typy RR záznamu patří: A – pro IPv4 adresy, MX – pro směrování pošty, AAAA – pro IPv6 adresy, a další. Tyto typy jsou registrovány u organizace IANA a jsou postupně doplňovány dle potřeby dalších protokolů, které s DNS pracují. Např. DNSSEC zavádí hned několik nových typů RR záznamů. V datech jsou pak uložené informace, které se liší dle typu, již zmiňovaný A záznam obsahuje IPv4 adresu. A ještě jedna technická poznámka. RR záznamy jsou sdruženy podle názvu, třídy a typu do RRsetů, které sdílejí stejné TTL. Pokud například máte více poštovních serverů, tak nelze při zadávání MX záznamů mít pro každý server jiné TTL.
Programy, které s DNS pracují, můžeme rozdělit na dvě základní kategorie: klient a server. Klient je program, který umí procházet hierarchickou strukturu DNS a zjišťovat informace uložené v RR záznamech. Server je pak program, který umí odpovídat na dotazy klientů, pro konkrétní doménová jména, pro které je nakonfigurován. Protože by implementace obecného DNS klienta do každého programu byla složitá, je v systémové knihovně implementovaný jenom jednoduchý DNS klient (stub resolver), který se umí zeptat jenom na konkrétní jméno a očekává odpověď v jednoduché formě. Z tohoto důvodu může být DNS klient i serverem, který poskytuje informaci tomuto stub resolveru. DNS server, který se chová jako klient, budeme nazývat resolver nebo také rekurzivní DNS (rDNS). Protože rDNS má většinou (nikoli nutně) vyrovnávací paměť, do které si ukládá výsledky již provedených dotazů, můžeme se také setkat s označením kešující DNS. DNS server, který odpovídá na dotazy, nazveme autoritativní DNS (aDNS). A aby to nebylo příliš jednoduché, tak DNS server může vystupovat v obou rolích zároveň. Na dotazy na doménová jména, pro které je server autoritativní, odpovídá přímo – chová se jako aDNS, ostatní dotazy přeposílá jiným autoritativním serverům, tedy se chová jako rekurzivní DNS server. Nicméně tato konfigurace není doporučována a z různých důvodů je lepší mít tyto dvě role – rekurzivní a autoritativní – odděleny.
Pomalu jsme se propracovali přes definice k tomu, co se vlastně stane, když program potřebuje např. přeložit jmenný název na IP adresu. Překlad jména na IP adresu se provede voláním systémové funkce getaddrinfo, která vytvoří strukturu addrinfo. Struktura addrinfo umí IPv6 i IPv4 adresy a program ji může využít dále pro vytváření IP spojení. Co se vlastně všechno stane ve chvíli, kdy dojde k volání getaddrinfo? Otevřete prohlížeč a chcete se podívat na stránky vlády České Republiky, napíšete tedy do svého prohlížeče www.vlada.cz. Prohlížeč zavolá funkci:
getaddrinfo("www.vlada.cz", 80, &hints, &result).
Voláním této funkce se předá kontrola stub resolveru, který se nejprve podívá do lokálního souboru /etc/hosts (a jsme zpátky u hosts.txt) a pokud informaci nenalezne zde, zeptá se rDNS serverů nakonfigurovaných v /etc/resolv.conf. Pořadí dotazování lze nakonfigurovat v /etc/nsswitch.conf, v dnešních systémech se mezi tyto dvě metody zařazuje ještě multicast DNS. Ale pojďme zpátky k našemu dotazu na www.vlada.cz. rDNS server přijme dotaz a podívá se, zda-li odpověď nemá ve vyrovnávací paměti, pokud ano, vrátí rovnou tuto odpověď. V opačném případě začne hierarchicky od kořenové úrovně (jinak také root, v DNS je reprezentovaný nepovinnou tečkou úplně napravo v doménovém jméně) prohledávat DNS databázi. Aby vůbec mohl začít, musí mít staticky nakonfigurované DNS servery pro kořenovou úroveň. Takových serverů je v současné době 13. Náš rDNS se zeptá náhodně vybraného kořenového serveru na „www.vlada.cz“, tento server ovšem tuto informaci neví (protože je systém hierarchický, distribuovaný a decentralizovaný), ale ví, že správcem domény .cz je CZ.NIC, resp. jeho DNS servery. Proto odpoví „já to nevím, ale zeptej se serverů CZ.NICu“, prakticky to pak vypadá takto:
;; QUESTION SECTION:
;www.vlada.cz. IN A
;; AUTHORITY SECTION:
cz. 172800 IN NS F.NS.NIC.cz.
cz. 172800 IN NS C.NS.NIC.cz.
cz. 172800 IN NS E.NS.NIC.cz.
cz. 172800 IN NS B.NS.NIC.cz.
cz. 172800 IN NS A.NS.NIC.cz.
cz. 172800 IN NS D.NS.NIC.cz.
;; ADDITIONAL SECTION:
A.NS.NIC.cz. 172800 IN A 217.31.205.180
A.NS.NIC.cz. 172800 IN AAAA 2001:1488:dada:176::180
B.NS.NIC.cz. 172800 IN A 217.31.205.188
B.NS.NIC.cz. 172800 IN AAAA 2001:1488:dada:184::188
C.NS.NIC.cz. 172800 IN A 195.66.241.202
C.NS.NIC.cz. 172800 IN AAAA 2a01:40:1000::2
D.NS.NIC.cz. 172800 IN A 193.29.206.1
D.NS.NIC.cz. 172800 IN AAAA 2001:678:1::1
E.NS.NIC.cz. 172800 IN A 194.146.105.38
F.NS.NIC.cz. 172800 IN A 193.171.255.48
F.NS.NIC.cz. 172800 IN AAAA 2001:628:453:420::48 rDNS server si přečte, že se má zeptat serverů CZ.NICu a pošle dotaz jednomu z těchto serverů. Zde se situace opakuje a rDNS je odkázán na servery ns.vlada.cz a ns2.gts.cz, které obsluhují doménu vlada.cz. Výsledek vypadá takto:
;; QUESTION SECTION:
;www.vlada.cz. IN A
;; AUTHORITY SECTION:
vlada.cz. 18000 IN NS ns.vlada.cz.
vlada.cz. 18000 IN NS ns2.gts.cz.
;; ADDITIONAL SECTION:
ns.vlada.cz. 18000 IN A 212.47.23.110 Opět je vyslán další DNS dotaz, tentokrát již na doménové servery domény vlada.cz, tedy například ns.vlada.cz. Tento server již požadovanou informaci ví a našemu dotazujícímu se serveru odpoví:
;; QUESTION SECTION:
;www.vlada.cz. IN A
;; ANSWER SECTION:
www.vlada.cz. 600 IN A 212.47.23.116 Nyní rDNS konečně dostal odpověď, kterou potřeboval, a na úplně původní dotaz stub resolveru může odpovědět s informací 212.47.23.110. Veškeré informace, které při získávání IP adresy pro server www.vlada.cz dostal, si uloží do vyrovnávací paměti, včetně informace o TTL. Příště, pokud dostane stejný dotaz v časovém limitu, který je pro www.vlada.cz 10 minut, bude moci odpovědět přímo z vyrovnávací paměti.
Graficky to vypadá takto:
V tuto chvíli je potřeba se ještě na chvíli zastavit u sekce ADDITIONAL. V této sekci posílá aDNS tzv. GLUE záznamy. Představme si situaci, kdy kořenové nameservery pošlou odpověď: „nedokáži ti odpovědět, co je www.vlada.cz, ale možná to ví a.ns.nic.cz.“ Pokud by v další sekci DNS zprávy nepřišly informace o IP adrese serveru a.ns.nic.cz, musel by rDNS zjistit IP adresu serveru a.ns.nic.cz sám. Jak by nejspíš vypadala odpověď kořenového serveru na dotaz ohledně IP adresy a.ns.nic.cz? „Nedokáži ti odpovědět, ale možná to ví a.ns.nic.cz“. V tu chvíli bychom se dostali do nekonečné smyčky, a původní dotaz by zůstal nezodpovězen.
V další části seriálu o DNSSEC si řekneme něco o struktuře DNS zprávy, příznacích v DNS dotazech a DNS odpovědích, a omezeních a rozšířeních DNS protokolu.
Malý slovníček pojmů:
aDNS – Autoritativní DNS – DNS server, který ví informace o konkrétní zóně, tedy je pro tuto zónu autoritativní.GLUE záznam – informace o IP adrese, která se posílá navíc v odpovědích, kdy je delegace zóny směrovaná do nameserverů uvnitř zóny.
rDNS – Rekurzivní DNS – Resolver – DNS server, který umí rekurzivně procházet DNS strom a odpovídat na dotazy klientů.
RR záznam – Resource Record – jednotlivá položka v DNS, obsahuje vlastníka, TTL, typ, třídu, a data záznamu.
TTL – Time To Live – údaj označující dobu platnosti, po kterou si může rDNS držet RR záznam ve vyrovnávací paměti.
Zóna – část DNS stromu, která je delegovaná na samostatné DNS servery.
Autor je technickým ředitelem sdružení CZ.NIC.
ČLÁNKY DO MAILU