Řekněme, že sháníte informace o Technické univerzitě v Liberci. Do webového prohlížeče proto zadáte www.tul.cz a DNS klient ve vašem počítači dostane za úkol najít k tomuto jménu odpovídající IP adresu. Ve své konfiguraci má zapsáno, kde začít – IP adresu lokálního DNS serveru obsluhujícího místní síť.
Vznik dotazu
Celá DNS transakce začne tím, že klient na základě požadavku vašeho prohlížeče vytvoří DNS dotaz požadující záznam typu A pro jméno www.tul.cz a zašle jej lokálnímu serveru. Zatím necháme stranou vyrovnávací paměti a popíšeme postup řešení dotazu bez nich. Je znázorněn na obrázku, jednotlivé kroky jsou opatřeny pořadovými čísly – toto byl krok 1.
Hledání adresy pro www.tul.cz
Oslovený server se chopí řešení dotazu. Odpověď samozřejmě nezná, ale zaúkoluje svůj plnohodnotný resolver, jenž má k dispozici adresy kořenových serverů, u nichž začíná řešení všech dotazů. Lokální server některý z nich vybere, řekněme k.root-servers.net, a pošle mu stejný dotaz: hledám záznam typu A pro www.tul.cz (krok 2).
Hierarchické uspořádání domén svádí k myšlence, že dotaz bude postupně „probublávat“ hierarchií vzhůru. Tak to ale není, cestu nahoru absolvuje jedním skokem. Je to rychlejší a snadněji udržitelné – stačí, aby každý místní server znal třináct adres kořenových serverů, které jsou pro všechny společné a stabilní. Mívá je ve své konfiguraci a při startu si zjišťuje jejich aktuální složení pomocí tak zvaných přípravných dotazů (priming queries, podrobněji se problematice věnuje RFC 8109 Initializing a DNS Resolver with Priming Queries).
Průchod stromem
Hierarchické uspořádání se začne uplatňovat až při sestupu doménovým stromem dolů. Oslovený kořenový server zná situaci v kořenové doméně. Ví, že doména nejvyšší úrovně cz skutečně existuje a kdo jsou její autoritativní servery. Na rozdíl od lokálního serveru však nemá čas dotaz řešit – dostává jich příliš mnoho. Proto rovnou pošle tazateli odpověď, která však místo požadovaného záznamu A pro www.tul.cz napovídá, kde se ptát dál (krok 3). V tomto konkrétním případě bude obsahovat informace o autoritativních serverech pro doménu cz:
cz. NS d.ns.nic.cz. cz. NS a.ns.nic.cz. cz. NS b.ns.nic.cz. cz. NS c.ns.nic.cz. d.ns.nic.cz. AAAA 2001:678:1::1 c.ns.nic.cz. AAAA 2001:678:11::1 b.ns.nic.cz. AAAA 2001:678:10::1 a.ns.nic.cz. AAAA 2001:678:f::1 d.ns.nic.cz. A 193.29.206.1 c.ns.nic.cz. A 194.0.14.1 b.ns.nic.cz. A 194.0.13.1 a.ns.nic.cz. A 194.0.12.1
Lokální server nyní může sestoupit o jedno patro hierarchie níže. Dozvěděl se jména a adresy autoritativních serverů pro doménu cz, takže stejný dotaz (hledám záznam typu A pro www.tul.cz) položí jednomu z nich, například a.ns.nic.cz (krok 4). Opakuje se podobná situace jako v kořeni, jen jsme o něco blíže řešení. Oslovený server opět nezná odpověď a nemá kapacitu dotaz řešit, ale zná doménu cz. Proto ví, že tul.cz skutečně existuje a jaké jsou její autoritativní servery. Tuto informaci pošle tazateli jako odpověď (krok 5):
tul.cz. NS tul.cesnet.cz. tul.cz. NS bubo.tul.cz. bubo.tul.cz. A 147.230.16.1 bubo.tul.cz. AAAA 2001:718:1c01:16::aa
Lokální server se zase o krok přiblížil vyřešení dotazu. Vybere si jeden z autoritativních serverů pro doménu tul.cz, třeba bubo.tul.cz, a zopakuje mu svůj dotaz (krok 6). Jelikož je poptávané jméno jen o jedno patro níže, je jisté, že tentokrát již dostane definitivní odpověď (krok 7). V daném případě:
www.tul.cz. CNAME novy.tul.cz. novy.tul.cz. A 147.230.18.195
Říká se v ní, že jméno www.tul.cz je ve skutečnosti přezdívkou pro novy.tul.cz, jehož adresa je v odpovědi také obsažena. Předá ji klientovi (krok 8). Zdůrazněme, že postup řešení bude víceméně stejný odkudkoli z celého Internetu. Lišit se bude jen výběr oslovených serverů, vždy však lokální server nejprve osloví jeden z kořenových serverů, pak některý z autoritativních serverů pro doménu cz a do třetice vybere jeden z autoritativních serverů domény tul.cz. Obecně platí, že dotaz se vždy vyhoupne do kořene doménového stromu a pak postupně sestupuje po jednotlivých patrech blíže a blíže danému cíli.
Kořenová zóna
Možná vám trochu vrtá hlavou, jak může kořenový server poslat záznam typu A třeba pro a.ns.nic.cz. Kořenová doména obsahuje pro cz záznamy typu NS, v nichž jsou uvedena doménová jména jejích autoritativních serverů. Vyvstává klasický problém slepice versus vejce: abychom se mohli zeptat autoritativního serveru a.ns.nic.cz na informace ohledně domény cz, potřebujeme jeho adresu. Ta je ovšem uložena kdesi v doméně cz.
Tento problém řeší tak zvané slepující záznamy (glue records). Jedná se o adresní záznamy (typy A a AAAA) umístěné ve vyšších patrech doménové hierarchie, než by jim náleželo. Jestliže jméno autoritativního serveru pro určitou poddoménu samo leží v této poddoméně, je standardním postupem nezjistitelné. Proto se do nadřízené domény společně se záznamem typu NS uvádějícím jméno serveru umístí i záznamy obsahující IP adresy tohoto serveru.
Kořenová doména tedy obsahuje slepující záznamy typu A a AAAA pro a.ns.nic.cz a doména cz podobně obsahuje slepující záznam A pro bubo.tul.cz. Pokud server odesílá příslušný záznam NS, automaticky do své zprávy přibalí i odpovídající slepující záznamy, pokud je má k dispozici.
Vyrovnávací paměť (cache)
V příkladu jsme zatím zcela ignorovali existenci vyrovnávacích pamětí (cache). Nastal čas věnovat jim trochu pozornosti. Lokální server si samozřejmě uloží získanou odpověď pro www.tul.cz a pokud se v době jeho životnosti bude po této informaci shánět některý z místních klientů, odpoví mu rovnou. Celá DNS komunikace pak bude mít jen dva kroky: klient se zeptá místního serveru a ten mu rovnou pošle odpověď s příznakem, že není autoritativní.
Server si však neukládá jen výsledné řešení, ale veškeré informace, které během jeho hledání získal. V tomto případě autoritativní servery pro domény cz a tul.cz. Když po chvíli brouzdání po stránkách pošlete elektronickou poštou na adresu info@tul.cz nějaký dotaz, bude váš poštovní server poptávat záznamy typu MX pro doménu tul.cz. Situaci ilustruje další obrázek.
Hledání poštovních serverů pro tul.cz s využitím cache
Jeho resolver se obrátí na lokální DNS server, který má ve vyrovnávací paměti platné údaje o autoritativních serverech pro tuto doménu. Díky tomu se zeptá rovnou některého z nich a obratem se dozví:
tul.cz. MX 0 bubo.tul.cz. tul.cz. MX 50 tul.cesnet.cz. bubo.tul.cz. A 147.230.16.1 bubo.tul.cz. AAAA 2001:718:1c01:16::aa
Dorazí-li zanedlouho lokálnímu DNS serveru dotaz na www.liberec.cz (chystáte se studovat v Liberci a zajímá vás, co je ve městě k vidění) využije uložené informace o autoritativních serverech pro doménu cz a zeptá se některého z nich, aniž by začínal u kořenového serveru. Jak by to zhruba vypadalo, vidíte na dalším obrázku.
Hledání adresy www.liberec.cz s využitím cache
Při řešení dotazů a uplatňování vyrovnávacích pamětí hraje klíčovou roli skutečnost, že doménové jméno je zároveň jednoznačným popisem cesty doménovým stromem, jež vede k získání požadované informace. Díky tomu každý z oslovených serverů okamžitě ví, kudy se má pokračovat k vyřešení. Zároveň si dokáže najít ve vyrovnávací paměti nejkonkrétnější relevantní informaci a tu využít k omezení síťové komunikace a zrychlení odezvy.
Rekurzivní a nerekurzivní chování
V příkladu z předchozí části jsme popsali dva výrazně odlišné způsoby chování DNS serverů. Zatímco lokální server se dotazu chopil, vyřešil jej a poslal výslednou odpověď, kořenový server se dotazem nezabýval a jako odpověď poskytl obratem informace o serverech, které mají blíže k řešení. Pro tyto dva druhy chování existují i oficiální názvy.
Rekurzivní řešení dotazu je takové, kdy se server dotazu ujme, vyřídí veškerou potřebnou korespondenci až po získání odpovědi, kterou pak odešle tazateli. Rekurzivní chování server samozřejmě zatěžuje. Musí si uchovávat datové struktury pro rozpracované dotazy, přeposílat dotazy a podle reakcí na ně se rozhodovat, jak pokračovat dál. Hlavní a základní výhodou rekurzivního řešení dotazů je, že si server plní vyrovnávací paměť. Procházejí jím dílčí i finální odpovědi, které si ukládá a může je využít při řešení dalších dotazů. Toto chování je typické pro lokální servery, které fungují jako rekurzivní resolvery obsluhující jednoduché resolvery místních strojů.
Nerekurzivní řešení dotazu znamená, že server jednoduše odkáže tazatele jinam. Obdrží dotaz, nahlédne do svých dat, odešle jako odpověď informace o autoritativních serverech bližších k řešení (nebo chybový kód, pokud jste se zeptali na doménu, k níž nemá co říci) a pustí dotaz z hlavy. Nemusí si nic uchovávat, zátěž serveru je minimální, což je přesně ten důvod, proč se nerekurzivně chovají autoritativní servery v horních patrech doménové hierarchie – tedy kořenové a servery domén nejvyšší úrovně.
Obecné doporučení zní, že v každé síti připojené k Internetu by měl být místní rekurzivní server, na nějž se obracejí zdejší klienti. Jeho hlavní úlohou je poskytnout společnou vyrovnávací paměť a omezit tak objem DNS komunikace směřující do Internetu. Pokud hledáte hojně používaný server, třeba www.seznam.cz, skoro jistě budete obslouženi z vyrovnávací paměti, protože adresu před vámi požadoval někdo jiný. Čím více klientů se schází na jednom lokálním serveru, tím vyšší je pravděpodobnost opakování dotazů a efektivita využití uložených informací.
Proto není dobrý nápad stavět rekurzivní servery na každém rohu. Ideální počet je jeden pro celou místní síť. Tím ovšem vzniká slabé místo, protože při jeho výpadku přestane místním strojům fungovat DNS. Pokud je síť větší, je rozumné postavit do ní dva rekurzivní DNS servery – jeden hlavní a jeden záložní pro případ výpadku prvního. Více rozhodně ne.
Na druhé straně je však třeba upozornit, že rekurzivnímu serveru se dají podstrčit falešné informace a on následně bude své klienty mystifikovat. Je proto velmi důležité, aby byl správně konfigurován a chránil se před podobnými pokusy. Naprostou samozřejmostí by mělo být, že rekurzivní služby poskytuje jen strojům z místní sítě, nikoli veřejně do Internetu.
Pokud má koncová síť přidělenu vlastní doménu, otevírá se zajímavá otázka vztahu autoritativních serverů této domény a pomocných (rekurzivních) serverů koncové sítě. Lze k ní přistoupit dvěma způsoby: puristicky nebo úsporně. Vhodnější puristická varianta používá zcela oddělené servery, zatímco úsporná sází na jeden společný server pro obě role.
Kniha Domain Name System
Text, který jste právě dočetli, je součástí knihy „Domain Name System: Principy fungování DNS a praktické otázky spojené s jeho používáním“ autorů Pavla Satrapy a Ondřeje Filipa, která vyšla v Edici CZ.NIC.
ČLÁNKY DO MAILU