Domain Name System (DNS)

Z hlediska obsahu je klíčovou komponentou DNS doménový strom. V této datové struktuře jsou hierarchicky uspořádány veškeré informace, které obsahuje. Všichni víte, že doménová jména se zapisují v podobě m1.jr.lixis.cz – jednotlivé domény jsou v zápisu oddělovány tečkami a uvádějí se v pořadí od konkrétních k těm nejobecnějším. Jméno však zároveň funguje – směrem zezadu dopředu – jako popis průchodu doménovým stromem.

V tomto konkrétním případě říká, že z kořene doménového stromu je třeba jít do domény cz (označující Českou republiku), z ní pokračovat do její poddomény lixis (LIXIS s.r.o v Jaroměři), dále pokračovat do poddomény jr (moje pracoviště doma) a v ní navštívit poddoménu m1. Doménové jméno tedy jednoznačně identifikuje konkrétní uzel v doménovém stromě a zároveň popisuje cestu od kořene k němu. Zejména tato druhá vlastnost je klíčová, protože je využívána při hledání odpovědi.

Zastavme se ještě chvíli u vlastního doménového stromu. Jako každý správný strom obsahuje jediný kořen – takzvanou kořenovou doménu (root domain). Jelikož je jediná, nemá smysl ji ve jméně uvádět, a proto ji v zápisu nenajdete. V případě nutnosti se zapisuje jako samotná tečka . (tímto způsobem je také znázorněna na našich obrázcích).

Některé nástroje či konfigurační soubory rozlišují mezi absolutně a relativně zadaným doménovým jménem. Absolutně zadané jméno končí tečkou – například www.nic.cz. – a znamená to, že je úplné, protože obsahuje všechny údaje až po kořenovou doménu. Používá se pro ně také pojem plné či plně specifikované doménové jméno, v originále Fully Qualified Domain Name (FQDN).

Pokud na konci není tečka, chápe se jako jméno relativní a příslušný program si k němu doplní, či alespoň může doplnit, nějakou koncovku. Zkuste si třeba do WWW prohlížeče zadat jako cílovou adresu jen samotné www a uvidíte, že si k němu iniciativně něco doplní a přistanete na konkrétním webu. Relativní jména jsou běžná v datových souborech DNS, kde se vždy vztahují k aktuální doméně. Jinak bychom se upsali. Problematika je složitější, protože nelze chtít po uživatelích, aby jména důsledně ukončovali tečkou. Operační systémy a aplikace proto odhadují, zda jméno bez tečky na konci skutečně je či není relativní.

Hlavní úlohou kořenové domény je držet celý strom pohromadě a poskytnout výchozí bod pro řešení dotazů. Bezprostředně pod ní se nacházejí takzvané domény nejvyšší úrovně (top-level domains, TLD). Původně vznikly s cílem stručně charakterizovat držitele domény a zároveň snížit pravděpodobnost konfliktů.

TLD znamená Top Level Domain (domény nejvyšší úrovně).

Když DNS přišlo na svět, mělo na nejvyšší úrovni pět domén: com pro komerční firmy, edu pro vzdělávací instituce, gov pro vládu, mil pro vojáky a org pro organizace nezařaditelné do žádné z ostatních kategorií. Záhy k nim přibyly domény jednotlivých států a postupem času i další. Podle určení a klíčových vlastností je lze rozdělit do čtyř základních kategorií:

Obecné domény (generic top-level domains, gTLD) navazují na původní členění. Dělí se do dvou odrůd: Nesponzorované obecné domény, jako například com, net, org nebo info, patří do přímé kompetence ICANN. Sponzorované obecné domény (sTLD) jsou založeny a spravovány určitou organizací, která určuje podmínky pro registraci v nich. Bývají vymezeny geograficky nebo tematicky, například v sTLD aero mohou získat poddoménu jen subjekty působící v oblasti letectví. Jako další příklady sponzorovaných obecných domén lze jmenovat asia, jobs, museum či xxx.

Státní domény (country-code top-level domains, ccTLD) jsou domény přidělené jednotlivým státům. Jejich zkratky odpovídají (až na několik výjimek) dvoupísmenným zkratkám příslušných států podle standardu ISO 3166–1. Jistě nejvýznamnější výjimkou je doména eu pro Evropskou unii. Za zmínku stojí též britská doména uk, přestože Velká Británie má ve zmiňovaném standardu přidělenu zkratku gb. Důvody výjimek jsou zpravidla historické.

Státní domény v národních abecedách (internationalized ccTLD, IDN ccTLD) odpovídají, podobně jako předchozí kategorie, jednotlivým státům. Jejich názvy jsou ovšem zapsány v národních abecedách, které nevycházejí z latinky (čínská, arabská a další písma).

Infrastrukturní doména (infrastructure top-level domain) je pouze jediná. Jedná se o doménu arpa, která slouží pro některé interní mechanismy DNS, zejména pro reverzní převody IP adres na jména a pro ENUM. Má poměrně zajímavou historii – původně byla určena pro agenturu ARPA (Advanced Research Projects Agency), jež stála u kolébky Internetu. Později doména změnila svůj význam a odpovídajícím způsobem byl upraven i význam zkratky, v současnosti znamená Address and Routing Parameter Area.

Po bouřlivém začátku, kdy kolem poloviny 80. let vznikla valná většina domén nejvyšší úrovně, nastalo dvacetileté období klidu. Kořenová doména byla tou dobou velmi konzervativní, obsahovala kolem 300 poddomén a narůstala průměrným tempem jedné až dvou nových TLD ročně. Roku 2005 pak byl zahájen proces vedoucí ke vzniku celé řady nových obecných domén.

Kromě výše uvedených čtyř existuje ještě jedna skupina doménových jmen nejvyšší úrovně. Mezi předchozí ovšem nepatří, protože tyto domény neexistují a ani existovat nemohou. RFC 2606 rezervovalo několik jmen nejvyšší úrovně pro speciální účely:

Kromě nich byly vyhrazeny ještě tři domény druhé úrovně (example.com, example.net a example.org), opět pro potřeby příkladů v dokumentaci. Tyto domény nejsou součástí doménového stromu a mohou být volně využívány k daným účelům.

Jelikož se později objevilo ještě několik jmen rezervovaných pro speciální účely, RFC 6761 Special-Use Domain Names je shrnulo a zavedlo pro ně registr, který obhospodařuje IANA. Aktuální přehled doménových jmen se speciálním významem najdete na webu organizace IANA.

Poddoménami TLD jsou tak zvané domény druhé úrovně. K jejich přidělování existují dva základní přístupy: Většinou jsou přidělovány již konkrétním organizacím či jednotlivcům. Tímto způsobem je spravována například naše doména cz, proto třeba Technická univerzita v Liberci disponuje doménou tul.cz, Seznam doménou seznam.cz a podobně.

V některých doménách se snaží na druhé úrovni rozlišit charakter vlastníka, podobně jako původní nejvyšší domény com, edu a spol. Domény organizací a dalších vlastníků se pak nacházejí až na třetí úrovni. Nejznámějšími příklady tohoto uspořádání jsou Rakousko (at), Velká Británie (uk) či Austrálie (au), ale je jich mnohem víc. Seznam dostupných koncovek doménových jmen obsahuje Public Suffix List, který najdete na publicsuffix.org/list/. Například vídeňská univerzita je držitelem domény univie.ac.at, kde ac na druhé úrovni signalizuje akademickou instituci. Tento způsob organizace domén je výrazně menšinový a spíše se od něj ustupuje – třeba v Rakousku je dnes již možná také registrace domén druhé úrovně.

Hloubka doménového stromu je omezena na 127 úrovní. Tento limit je však ryze teoretický, v praxi se jen zřídka setkáte s hloubkou větší než pět. Výjimkou jsou různé speciální mechanismy – ENUM pro telefonní čísla a zejména reverzní dotazy pro IPv6, které zasahují až do 35. úrovně. To je hodně extrémní případ, přesto se dostal jen do čtvrtiny maximální přípustné hloubky.

Když už jsme u extrémů, zmiňme se o existenci alternativních DNS stromů. My se věnujeme „originálnímu a jedině pravému DNS“. Kromě něj ovšem existují i jeho vedlejší odnože, které používají stejné protokoly, technologie i programy, jen jejich doménový strom je odlišný. Má svůj vlastní kořen, ze kterého obvykle vedou odkazy na všechny TLD oficiálního DNS, ovšem kromě nich ještě některé navíc.

Důvody pro jejich existenci mohou být ideové (nesouhlas s některými pravidly a omezeními, jimž podléhá standardní kořenová doména), komerční, nebo se může jednat o čistě interní záležitost určité organizace.

Jejich společnou vlastností je, že vyžadují speciální konfiguraci na straně strojů, které DNS prohledávají, a jejich dosah bývá velmi omezený. Drtivá většina Internetu o nich nemá tušení. Hlavním problémem jejich existence je samozřejmě nekonzistence informací. Kromě toho vznikají nepříjemné konflikty, pokud některý z alternativních kořenů vytvoří svou specifickou TLD a později je stejnojmenná doména založena v oficiálním DNS, což se přihodilo například doméně biz.

Internetová komunita nepohlíží na alternativní doménové stromy s žádným nadšením, což se odráží i v RFC 2826 IAB Technical Comment on the Unique DNS Root. Jeho obsah by se dal stručně shrnout heslem „jeden Internet – jedno DNS“. I nám se existence alternativních doménových stromů jeví jako krajně problematická a nebudeme se jim více věnovat.

Klíčovou úlohu v celém systému hrají servery. Obsahují jednotlivé části oné obrovské distribuované databáze, zasílají si dotazy a odpovědi a spolupracují při distribuci informací. Díky jejich vzájemné provázanosti a spolupráci celý systém vůbec může fungovat. DNS servery mají ke konkrétním doménám různý vztah, ze kterého pak vyplývá jejich úloha při řešení dotazů. Pro určitou konkrétní doménu může mít server jednu z následujících rolí:

Hlavním smyslem rekurzivních serverů je poskytnout společnou vyrovnávací paměť pro místní klienty. Aby se například adresy často používaných webů nehledaly znovu a znovu. Zopakuje-li se dotaz na jméno, které má rekurzivní server v paměti, rovnou pošle odpověď. Zvyšuje tak efektivitu celého systému, zmenšuje počet dotazů a odpovědí přenášených po síti a zrychluje odezvy. Jeho odpovědi samozřejmě nejsou autoritativní. Proto se pro něj používá také pojem pomocný server (caching only).

Ještě jednou zdůrazněme, že výše zmiňované role serverů se vždy vztahují ke konkrétní doméně. Jeden a tentýž server může být primární pro tři domény, sekundární pro dalších pět a pomocný pro všechny ostatní. Rozhoduje o tom pouze a jedině jeho konfigurace.

Z pohledu DNS komunikace není žádný rozdíl mezi primárním a sekundárním serverem. Dokonce ani není viditelný. Pro doménu se ukládají (v záznamech typu NS) všechny autoritativní servery, primární a sekundární se nijak nerozlišují. Odpověď v sobě nese příznak (označovaný AA – Authoritative Answer), zda je autoritativní nebo nikoli. Jeho hodnota závisí na tom, zda odpověď odeslal přímo některý z autoritativních serverů, nebo zda ji odeslal server pomocný ze své vyrovnávací paměti.

Rozdělení na primární a sekundární servery je čistě organizační záležitost, která se promítá do jejich konfigurace. Týká se toho, jak data vznikají, nikoli jejich věrohodnosti. Z pohledu DNS jsou odpovědi všech autoritativních serverů pro doménu stejně důvěryhodné. Některé domény koncept primárních a sekundárních serverů vůbec nepoužívají. Data mají například uložena v databázi, ze které si je berou jejich autoritativní servery. Synchronizaci jejich obsahu zajišťují databázové prostředky.

Mimochodem, jedny z nejošklivějších chyb vznikají, pokud se rozejde obsah primárního serveru se sekundárními. K této situaci může dojít, pokud správce domény upravuje její obsah ručně a zapomene zvětšit sériové číslo, které slouží jako indikátor změny. Sekundární servery si pak nechají původní obsah domény a jejich odpovědi se budou lišit od primárního. Jednotliví klienti se budou obracet na různé autoritativní servery (v závislosti na softwarové implementaci klienta a dobách odezvy jednotlivých serverů) a budou dostávat nekonzistentní odpovědi. Rozložení příjemců špatných odpovědí bude v podstatě náhodné, což řešení problému rozhodně neulehčí.

Případné problematické stavy ještě zhoršují pomocné servery. Na jedné straně výrazně zkracují doby odezvy DNS a snižují zátěž autoritativních serverů, na straně druhé však do něj zavádějí určitou setrvačnost. Dojde-li ke změně, vyrovnávací paměti pomocných serverů nadále obsahují původní údaje a dokud nevyprší jejich platnost, budou je poskytovat svým tazatelům. Tyto servery jsou rozesety po celém světě, jsou zcela mimo působnost správce domény a dotyčné záznamy si uložily v různém čase. Postupně budou nahrazovány aktuální verzí, ale tento proces může trvat několik dnů. Správce domény jej může ovlivňovat jen nepřímo – vhodným nastavením životnosti záznamů.

DNS neposkytuje za každých okolností stoprocentně konzistentní a aktuální informace. Je to cena, kterou platíme za jeho škálovatelnost a efektivitu. Obecně platí, že čím významnější je doména, tím větší péče bývá věnována jejím autoritativním serverům. Má jich zpravidla větší počet a jsou vhodně rozmístěny v různých částech Internetu.

Počet autoritativních serverů poslouží jako orientační měřítko významu domény. Posuďte sami: doména tul.cz má dva, nic.cz tři, doména cz čtyři, com hned třináct a stejný počet má i kořenová doména. Ve skutečnosti je jich podstatně více, protože za jedním jménem v záznamu typu NS se může skrývat mnoho fyzických serverů.

Vyšší počet autoritativních serverů má dva významy: větší robustnost, protože lépe dokáže překonat i větší výpadky sítě, a také rozkládání zátěže. Na autoritativní servery velkých domén se valí obrovské množství dotazů, jejich obsluhování více stroji rozloženými v různých částech sítě je holou nezbytností.

Zcela zásadní roli mají autoritativní servery kořenové domény, tak zvané kořenové servery (root servers). U nich začíná řešení všech dotazů, které pak postupuje doménovým stromem po jednotlivých patrech od kořene až k cíli. Případná nedostupnost všech kořenových serverů by učinila DNS nefunkčním. Proto se za jejich třinácti adresami ve skutečnosti skrývají stovky serverů – konkrétně v polovině roku 2023 jich bylo zhruba 1500. Používají se tak zvané výběrové adresy (anycast), kdy se stejná adresa přidělí několika strojům a směrování se postará o doručení paketu nejbližšímu z jejích majitelů.

Podrobnosti o kořenových serverech včetně mapky jejich rozložení najdete na adrese https://www.root-servers.org. Budiž autorům a správcům DNS připsáno ke cti, že za celou jeho historii nedošlo k vyřazení všech kořenových serverů, přestože se vyskytlo několik cílených útoků na ně. Zmíněných třináct adres kořenových serverů je velmi konzervativních, protože je musí znát miliony dalších serverů v celém Internetu. Mění se proto zhruba rychlostí pohybu kontinentů. Jejich nejvýznamnější změnou v posledních letech byla postupná implementace IPv6 a s ní přidávané IPv6 adresy.

Máme tedy data, máme i servery a zbývá nám už jen klient, který se bude systému ptát. V oficiální terminologii se pro něj používá termín resolver (čili řešič). Jeho hlavní úlohou je zprostředkovávat místním aplikacím styk s DNS – na základě jejich požadavků sestavuje DNS dotazy, zasílá je serverům a zpracovává příchozí odpovědi. Obvykle také mívá vlastní vyrovnávací paměť, aby zbytečně neobtěžoval stále stejnými dotazy.

Resolver bývá součástí operačního systému. Z programátorského hlediska má zpravidla podobu knihovny funkcí, které tvoří jeho rozhraní (API) vůči aplikacím. Touto cestou mu jednotlivé programy zadávají úkoly a přebírají si výsledky. Uživatel se na něj přímo obrátit nemůže, proto bývají součástí systému jednoduché aplikace, jejichž prostřednictvím lze komunikovat s resolverem poměrně přímo a zjišťovat tak aktuální informace v DNS.

Podle schopností existují dva základní druhy resolverů:

Plnohodnotný (též rekurzivní) resolver je schopen samostatné existence. Zná adresy kořenových serverů a pokud nemá ve vyrovnávací paměti nic, co by pomohlo s vyřešením aktuálního dotazu, obrátí se na některý z nich. Podrobněji celý proces popíšeme vzápětí. Tento typ resolverů bývá základem výše zmíněných rekurzivních DNS serverů.

Jednoduchý resolver (v originále pahýlový, stub resolver) představuje minimalistický přístup. Potřebuje ke své činnosti adresu místního serveru (případně několika serverů), na který se má obracet se svými dotazy. Dostane-li od aplikace požadavek, převede jej do podoby DNS dotazu a pošle danému serveru. Ten dotaz vyřeší a pošle zpět výslednou odpověď. Jednoduchý resolver nezná adresy kořenových serverů a není schopen samostatné existence. Sám dotazy neřeší, jen je předává místnímu serveru. Součástí běžných operačních systémů bývají právě takové resolvery.

Jednoduchý resolver se snadněji implementuje. Sortiment jeho funkcí je omezený, a kód programu tudíž jednodušší. Vyžaduje však konfiguraci – potřebuje se dozvědět adresu lokálního serveru, který bude řešit jeho dotazy. Její nastavení musí zajistit místní správce, a to buď přímo odpovídajícím konfiguračním zásahem na koncovém stroji, nebo (častěji) prostřednictvím konfiguračního protokolu DHCP.

Nabízí se otázka, proč operační systémy neobsahují plnohodnotné resolvery. Jejich kód i nároky by sice byly o něco větší, rozdíl by však nebyl nijak zásadní a pro současný hardware v podstatě zanedbatelný. Zato bychom získali jednoduchost použití – plnohodnotný resolver je soběstačný a téměř bezúdržbový. Potřebuje jen adresy kořenových serverů, které se prakticky nemění, a případnou změnu by šlo řešit obvyklou cestou systémových aktualizací.

Tím bychom se ale připravili o hlavní výhodu, společnou vyrovnávací paměť. Jednoduché resolvery strojů v lokální síti posílají své dotazy místnímu rekurzivnímu serveru, který je řeší a výsledky si ukládá do vyrovnávací paměti. Jelikož se všechny lokální stroje obracejí na stejný server, mohou využívat záznamy, které zjistil při řešení dřívějších dotazů jejich sousedů. To podstatným způsobem zvyšuje efektivitu vyrovnávací paměti a snižuje objem síťového provozu odcházejícího mimo lokální síť.

Kromě toho může rekurzivní server něco přidat k datům z veřejného DNS stromu. Jestliže se například v místní síti používají neveřejné adresy, neměly by se objevit ve veřejném DNS. Ovšem interně pro ně chcete používat jména. Často se tato situace řeší tak, že se rekurzivní server nastaví jako autoritativní pro speciální doménu, která obsahuje záznamy s neveřejnými adresami. Tato doména není v doménovém stromě, takže nedostává dotazy zvenčí. Ovšem místní stroje mu posílají všechny své dotazy, takže jim může zasílat odpovědi z této nestandardní domény.

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.

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).

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:

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):

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ě:

Ří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.

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.

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.

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í:

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.

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.

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.

Hranice mezi zónami prochází vždy hranou doménového stromu, jež spojuje nadřazenou doménu spadající do jedné zóny s podřazenou, která je již v jiné zóně. Pro tyto hranice se používá pojem zónový řez (zone cut) a označují vlastně hranice zodpovědnosti jednotlivých subjektů. Zónový řez znamená „od tohoto místa spravuje připojený podstrom někdo jiný“. Dotyčný správce může skutečně spravovat celý podstrom, nebo jeho části odřízne a svěří do správy dalším subjektům. To už je čistě otázkou jeho rozhodnutí.

Podívejme se na příklad části doménového stromu na obrázku, který popsaný princip ilustruje. Správce kořenové zóny odřízl její poddoménu cz a svěřil ji CZ.NIC. Ten pochopitelně neobhospodařuje celý příslušný podstrom, ale opět svěřuje jednotlivé domény druhé úrovně subjektům, které o ně projeví zájem.

Takže například doménu tul.cz získala do správy Technická univerzita v Liberci a vznikla tak další zóna. Celou doménu zde obhospodařuje centrální správa sítě, proto pod tul.cz nenajdete žádné další řezy a zóna zahrnuje celý podstrom. Jiný přístup zvolila podstatně větší Univerzita Karlova, která delegovala fakultní domény do správy příslušných fakult. Pod zónou cuni.cz spravovanou centrálním Ústavem výpočetní techniky UK tak vznikly zóny mff.cuni.cz, lf1.cuni.cz, ff.cuni.cz a další, jejichž správu si zajišťují přímo odpovídající fakulty.

Existence zón se promítá i do obsahu DNS. V doméně bezprostředně nad zónovým řezem musí být informace o tom, že podřízená doména existuje, avšak má už jiné autoritativní servery. To zajišťují záznamy typu NS. Například doména cz proto obsahuje dvojici záznamů NS pro doménu tul.cz se jmény jejích autoritativních serverů bubo.tul.cz a tul.cesnet.cz. Jména obou serverů leží v zónách podřízených zóně cz, proto musí obsahovat také slepující (glue) záznamy s jejich adresami. Právě tyto záznamy pošle autoritativní server domény cz tazateli, který se bude zajímat o nějaké informace z domény tul.cz.

Každá zóna ve svém kořeni obsahuje záznam typu SOA (Start of Authority), ze kterého zjistíte jméno jejího primárního serveru, e-mail správce a časové konstanty, které ovlivňují zacházení s jejími daty.

Data zóny bývají na serveru uložena v podobě tak zvaného zónového souboru, jehož podobu definuje RFC 1035 pod názvem master file. Je to poněkud nezvyklé, protože formát lokálních dat by měl být spíše věcí implementace a některé se skutečně od standardní podoby odchylují. Nicméně většina serverů tuto syntaxi dodržuje a používá se také ve všech dokumentech o DNS.

Jedná se o textový soubor, v němž je každý záznam zapsán na jeden řádek. Pokud jsou data dlouhá (například v záznamu typu SOA), lze je pro lepší čitelnost uzavřít do závorek a rozdělit do několika řádků. Uvnitř závorek má konec řádku stejný význam jako mezera. Záznam má pět položek vzájemně oddělených libovolnou kombinací mezer a/nebo tabulátorů:

Doménové jméno určuje jméno, k němuž se záznam vztahuje. Bývá také označováno jako vlastník záznamu. Pokud je zakončeno tečkou, chápe se jako absolutní a úplné. V opačném případě se za ně doplní aktuální doména. Takže například jméno www v zónovém souboru pro nic.cz znamená www.nic.cz.

Jméno může na začátku záznamu zcela chybět, v takovém případě se zdědí z předchozího. Jestliže jako jméno použijete samotný znak @, označuje aktuální doménu. Tedy doménu, v jejímž zónovém souboru se vyskytuje nebo která byla určena direktivou $ORIGIN, jíž se zanedlouho budeme věnovat.

Životnost určuje počet sekund životnosti záznamu ve vyrovnávací paměti a třída jeho třídu. Jejich pořadí může být prohozeno. Údaje také mohou chybět a server za ně dosadí implicitní hodnoty. Poslední dvě položky jsou jako jediné povinné. Určují typ záznamu a v závislosti na něm pak data, která obsahuje.

Existují i servery, jež si lokálně data ukládají do databází, tedy principiálně odlišně od oficiální podoby. Hodnoty jednotlivých položek tvoří celá čísla, doménová jména, IP adresy a řetězce znaků. Jejich zápisy odpovídají běžným konvencím. V případě celých čísel zdůrazněme, že jsou zapisována v desítkové soustavě jako souvislé sekvence číslic. Nelze do nich vkládat oddělovače řádů (mezery, čárky a podobně).

Výše jsme uvedli, že zóna cz musí obsahovat záznamy NS pro autoritativní servery tul.cz a také odpovídající slepující záznamy. Příslušný úsek zónového souboru by vypadal takto:

Všimněte si, že všechna jména jsou relativní (nekončí tečkou), takže se za ně doplní doména, v jejímž souboru se vyskytují. Například tul proto znamená tul.cz.

Řetězce znaků, jsou-li souvislé, lze psát přímo tak jak jsou. Pokud však má řetězec obsahovat mezery, je třeba obklopit jej uvozovkami ("), aby nebyly pochopeny jako oddělovače položek. Řetězec v uvozovkách může obsahovat i konce řádků a být tedy rozdělen do několika řádků za sebou. Pokud má obsahovat uvozovky, vložte před ně zpětné lomítko ( \" ).

Tento přístup je obecný – chcete-li potlačit speciální význam libovolného znaku, zapište před něj zpětné lomítko. O vložení zpětného lomítka do řetězce se tudíž postará \. Zcela libovolný znak lze vložit konstrukcí \DDD, kde DDD jsou číslice udávající kód znaku v osmičkové soustavě. Také tyto znaky jsou interpretovány jako pasivní část textu a je potlačen jejich případný speciální význam.

Alternativním zápisem pro vložení uvozovek by tedy bylo \042 , protože znak " má ASCII kód 34, v osmičkové soustavě 42.

Ke zvýšení čitelnosti lze do zónového souboru vkládat prázdné řádky a komentáře. Ty začínají středníkem, všechny následující znaky až po konec řádku jsou interpretovány jako komentář a serverem ignorovány.

Kromě běžných záznamů se v zónovém souboru mohou objevit také tak zvané direktivy, které představují příkazy ovlivňující způsob interpretace souboru. Různé servery si přidávají vlastní, ale standardně jsou definovány jen tři, jež shrnuje tabulka.

Zónový soubor pro velmi zjednodušenou zónu tul.cz, která obsahuje jen web, server pro příjem pošty a jednu poddoménu s vlastním webem, by mohl vypadat například takto:

V souboru používáme relativní jména, abychom jej zkrátili a učinili o něco přehlednějším. U jmen ležících mimo tul.cz (zde například tul.cesnet.cz) je třeba nezapomenout na konci tečku, aby byla správně interpretována jako absolutní. Bez závěrečné tečky by tul.cesnet.cz bylo interpretováno jako tul.cesnet.cz.tul.cz.

Zde zónový soubor obsahuje kompletní data pro celou zónu. To odpovídá logice věci, nicméně není to nezbytné a pro velké zóny to nebude ani příliš praktické – se soubory obludné velikosti se po všech stránkách špatně pracuje. Bylo by klidně možné pro fm.tul.cz vytvořit samostatnou zónu s vlastním souborem:

Pokud jsou obsluhovány stejnými servery, není třeba ani do tul.cz zavádět delegaci záznamem NS. Tazatel hledající www.fm.tul.cz se propracuje k autoritativním serverům pro tul.cz, jež mají oba zónové soubory a rovnou mu odpovědí. Z původního zónového souboru by tedy stačilo vymazat závěrečné řádky (počínaje druhým $ORIGIN). Koncepčnější ale je přidat do rodičovské domény záznamy s delegací, stejně jako by podřízenou doménu spravoval jiný subjekt. Závěrečné řádky původního zónového souboru je tedy lépe nahradit dvojicí:

Pokud spravujete zónu s poddoménami, je jen na vašem rozhodnutí, zda ji celou uložíte do jednoho souboru, nebo zda ji rozdělíte po jednotlivých doménách – obě varianty mají své přednosti.

DNS je postaveno na principu distribuované správy, aby informace mohli upravovat místní správci. Proto bylo třeba vymyslet způsob převodu IP adresy na dotazované jméno, který by umožnil například doménu odpovídající síťovému prefixu 147.230.0.0/16 svěřit do správy organizaci, jíž byla přidělena dotyčná síť.

Řešením je prosté otočení adresy. Konkrétně z IPv4 adresy se vytvoří poptávané doménové jméno tak, že se vyjde z jejího standardního zápisu, v něm se obrátí pořadí jednotlivých bajtů a na konec se přidá přípona in-addr.arpa. Pokud bychom například hledali, pod jakým jménem je registrována adresa 147.230.16.27, poptávali bychom doménové jméno:

Síti 147.230.0.0/16 odpovídá v tomto pojetí doména 230.147.in-addr.arpa, kterou lze snadno svěřit do správy držiteli adresy. Distribuovaná správa je možná a informace nadále mohou být do DNS vkládány přímo tam, kde vznikají. Pro reverzní dotazy byl vytvořen speciální typ zdrojových záznamů nazvaný PTR (pointer ukazatel). Jeho hodnotou je doménové jméno odpovídající příslušné adrese.

Například dotaz na záznam typu PTR pro výše uvedené doménové jméno vás oblaží odpovědí, že náleží stroji web.tul.cz. TUL, jejíž doménu tul.cz jsme používali pro příklady v předchozí části, disponuje právě sítí 147.230.0.0/16. Zónový soubor pro její reverzní doménu 230.147.in-addr.arpa, který by odpovídal našemu příkladu výše, by vypadal následovně:

Jsme v reverzní doméně, relativní jména jsou proto vztažena k ní – například 1.16 znamená 1.16.230.147.in-addr.arpa. Veškerá jména z domény tul.cz musí být zapsána jako absolutní. Považujeme za rozumné držet celou zónu pohromadě v jednom souboru, nedelegovat její části do dalších zón.

Popsaný systém byl navržen v době, kdy IPv4 adresy patřily do tříd A, B nebo C a přidělované prefixy končily vždy na hranici bajtů. Když bylo v polovině 90. let nasazeno beztřídní adresování (CIDR, Classless Inter-Domain Routing), vznikl problém, protože najednou mohla koncová síť dostat prefix libovolné délky. Poskytovatel internetu, který má při správě adres roli lokálního internetového registru (LIR), například dostal pro své zákazníky k dispozici prefix 10.1.2.0/24.

Vzhledem k velikosti koncových sítí a aktuálním pravidlům se jej rozhodl rozdělit na čtyři části různé velikosti a ty přidělit jednotlivým zákazníkům:

Při zachování původní koncepce reverzních zón bylo jedinou možností, aby jejich společnou zónu 2.1.10.in-addr.arpa spravoval poskytovatel a na základě požadavků jednotlivých zákazníků do ní vkládal záznamy pro jejich stroje. Takové uspořádání je ale dost nepraktické a popírá princip, aby si reverzní zónu spravoval sám držitel příslušného prefixu. Bylo potřeba vymyslet způsob, jak reverzní zónu delegovat kdesi uprostřed bajtu.

S řešením přišlo RFC 2317 s názvem Classless IN-ADDR.ARPA delegation. Do reverzního jména navrhlo vložit další doménu, která popisuje rozdělení bajtu a umožňuje delegovat jednotlivé poddomény různým subjektům. Toto vložení nelze udělat obecně, protože adresní prostor je členěn podle potřeby, jeho jednotlivé části se liší a zdaleka ne každá potřebuje delegaci uvnitř bajtu.

Držitel či správce prefixu, na jehož konci došlo k rozdělení, musí tuto skutečnost zanést do odpovídající reverzní zóny. V bajtu, ve kterém došlo k rozdělení, zavede poddomény pro jeho jednotlivé části a hodnoty do nich rozdělí. Používají se k tomu záznamy typu CNAME (přezdívka).

Konkrétně v našem příkladu by poskytovatel v doméně 2.1.10.in-addr.arpa+; zavedl poddomény `+0/25, 128/26, 192/27 a 224/27 a delegoval je příslušným zákazníkům. Kromě toho by do domény 2.1.10.in-addr.arpa vložil záznamy CNAME, jimiž by převedl původní reverzní jména na jména v těchto poddoménách. Všechny adresy přidělené prvnímu zákazníkovi by byly převedeny do domény 0/25.2.1.10.in-addr.arpa, takže například jméno 15.2.1.10.in-addr.arpa by se stalo přezdívkou pro 15.0/25.2.1.10.in-addr.arpa. Pro adresy druhého zákazníka by přezdívky vedly do domény 128/26.2.1.10.in-addr.arpa – například 137.2.1.10.in-addr.arpa by se díky CNAME změnila na 137.128/26.2.1.10.in-addr.arpa a tak dále.

Výhodou je, že dělicí zónu lze připravit předem a celou, bez ohledu na to, zda adresy byly přiděleny nebo nikoli. Zóna bude obsahovat záznamy CNAME pro všech 256 možných hodnot a až při dotazu autoritativních serverů jednotlivých poddomén spravovaných zákazníky se zjistí, zda pro danou adresu existuje PTR záznam či nikoli. Okamžitě po přidělení prefixů by tedy poskytovatel mohl vytvořit zónový soubor pro doménu 2.1.10.in-addr.arpa s následujícím obsahem:

Poddomény pak budou obsahovat běžné záznamy typu PTR pro existující stroje. Reverzní zóna 0/25.2.1.10.in-addr.arpa spravovaná zákazníkem xyz1 by mohla obsahovat například:

Pro IPv6 adresy se používá analogický postup, jen je vzhledem k zápisu adres o něco složitější. Opět vychází ze zápisu adresy, který se rozvine na úplný tvar – tedy doplní se všechny vynechané nuly. Pořadí jednotlivých šestnáctkových číslic v adrese se obrátí a každá z nich se stane samostatnou doménou. Za ně se pak přidá konstantní přípona ip6.arpa. Vezměme jako příklad adresu 2001:db8:89ab:1:2a0:ecff:fe12:345. Doplníme chybějící nuly:

Poté otočíme pořadí šestnáctkových číslic, uděláme z nich poddomény a připojíme ip6.arpa. Výsledný dotaz tedy bude poptávat doménové jméno:

Tento přístup opět umožňuje delegovat poddomény v souladu s přidělenými částmi adresního prostoru, navíc to vzhledem k důsledné agregaci adres půjde dělat hierarchicky. Vlastní informace o příslušném doménovém jméně je uložena v záznamu typu PTR, stejně jako v případě IPv4.

Nikde není zaručeno, že dopředná a reverzní informace budou konzistentní. Tedy že odpověď získaná reverzním dotazem je skutečným doménovým jménem, pod nímž je zaregistrována daná adresa. Nesrovnalosti vznikají chybami, v horším případě úmyslně s cílem podvádět.

Nikdo totiž nemůže zabránit správci reverzní domény 230.147.in-addr.arpa, aby do ní zanesl, že některá ze zdejších adres přísluší třeba www.google.cz. Pokud na tom záleží (například při omezování přístupu ke službě podle klientovy domény), je záhodno si získané jméno ověřit – nechat si pro ně najít adresy a podívat se, zda je původní adresa mezi nimi. Pokud ne, nejsou data v reverzní doméně v pořádku.

Řekněme, že nejmenovaný server má povolen přístup pouze pro stroje z domény tul.cz. Dorazí-li mu paket z IPv4 adresy 147.230.33.44, získá reverzním dotazem jeho jméno, řekněme pc33.tul.cz. Jelikož se této informaci nedá věřit, poptá vzápětí záznamy typu A pro pc33.tul.cz. Ty už do DNS vkládá správce domény tul.cz a má je pod kontrolou. V odpovědi se dozví třeba:

Pak může nalezenému jménu důvěřovat, protože zkoumaná adresa se nachází v jeho záznamech A. Daleko častější chybou než úmyslné falšování je chybějící reverzní záznam. Nemálo správců se jejich údržbou nezatěžuje a pokus o zjištění jména k takové adrese skončí neúspěchem.

Jak už jsme uvedli, jméno určuje cestu doménovým stromem, jež vede od kořene (případně z jiného bodu, pokud je jméno relativní) až k dané doméně. Formálně je tvořeno posloupností tak zvaných jmenovek (label), jež jsou navzájem odděleny tečkami. Oficiálně se na ně vztahuje několik málo omezení:

Upřímně řečeno, jen málokteré z nich skutečně pocítíte. Nikdo nemá zájem vytvářet dlouhatananánská jména ve stylu

www.polni.mys.hrabosi.savci.prirodovedne.sbirky.narodnimuzeum.cz

a to se ještě pořád pohybujeme hluboko v povolené zóně — délka obludy dosahuje pětiny přípustné velikosti.

Jmenovky mohou teoreticky obsahovat ledacos. Postupem času se však objevila řada chyb a nedokonalostí programů používajích údaje z DNS, proto RFC 1035 doporučuje držet se u jednotlivých jemnovek následujících omezení:

Je lépe vyhýbat se řadě populárních znaků, jako jsou podtržítka, lomítka, dvojtečky, procenta či jiné exotičtější znaky národních abeced, které jsou velmi žádány v oblastech, jejichž písmo není odvozeno od latinky. Pro ně bylo vytvořeno rošíření IDN, kterému se budeme věnovat později.

Doménová jména musí být jednoznačná. Proto sourozenci v doménovém stromě (poddomény stejné rodičovské domény) musí mít odlišné jmenovky. Nebo opačně: pokud se vyskytuje několik záznamů se stejným jménem a typem, jsou považována za záznamy stejného vlastníka — například několik záznamů MX pro jednu doménu nebo několik IP adres jednoho počítače.

Tatáž jmenovka se samozřejmě může opakovat v různých místech doménového stromu — jako nejlepší příklad poslouží www, kterou najdeme na každém rohu.

Při porovnání se v DNS nerozlišují malá písmenka od velkých. Nemohou tedy existovat domény nic.cz a NIC.cz, protože jsou považovány za shodné. Na druhé straně se ale od DNS software požaduje, aby při předávání informací neměnil velikost znaků v nich obsažených. Takže například jméno k IP adrese při reverzním dotazu dostanete v té podobě, jak je zapsána v DNS databázi, i s případnými malými/velkými písmeny. Při jeho porovnávání s dalšími jmény ale velikost znaků nehraje roli. Zadáte-li do webového prohlížeče adresu www.NIC.cz, skončíte zcela korektně na stránce www.nic.cz.

Oficiálně se délka jedné jmenovky musí pohybovat v rozmezí od 0 do 63 znaků. Prázdnou jmenovku však nelze používat — byla vyhrazena pro kořenovou doménu. Jestliže jsme v předchozí kapitole psali, že pro zdůraznění absolutního jména se na jeho konec píše tečka (www.nic.cz.), vlastně to znamená, že za touto tečkou je ještě uvedena prázdná jmenovka kořenové domény.

V DNS zprávách se doménová jména nepřenášejí jako řetězce znaků, ale jako sled po sobě jdoucích jmenovek. Každá začíná jednobajtovou informací o své délce, za níž pak následují znaky tvořící vlastní obsah jmenovky. Přesněji řečeno, nejvyšší dva bity počátečního bajtu jmenovky jsou interpretovány jako kód určující její typ. Jejich hodnoty (binárně) mají následující význam:

Specifikace doporučují aby stejný formát používaly interně také aplikace, které s DNS pracují.

Formát zpráv, které si účastníci DNS komunikace vyměňují, definuje RFC 1035. Obsahuje celkem pět částí. Začíná pevnou hlavičkou se základními informacemi. Za ní naásleduje vlastní obsah, rozdělený do čtyř sekcí: dotaz, odpověď, autorita a doplňky. Rámcovou podobu DNS zprávy představuje obrázek. V základní podobě je přenášena protokolem UDP v jednom datagramu a její celková délka nesmí překročit 512 bajtů.

K párování dotazů a odpovědí slouží počáteční Identifikátor (ID). Odesílatel pak do něj pro každý svůj dotaz vloží jednoznačnou hodnotu, kterou server zkopíruje do odpovědi. 16 bitů následujících za identifikátorem je věnováno různým příznakům a stavovým kódům charakterizujícím zprávu. Jednobitových příznaků je definováno celkem sedm:

Čtyřbitová položka OpKód (Opcode) je spojena s dotazem. Upřesňuje, jaká činnost se od serveru očekává. Nejběžnější hodnotou je nepochybně nula, která ohlašuje standardní dotaz, kdy se ke jménu hledají záznamy daného typu. Další možné varianty shrunuje tabulka, k nejvýznamějším z nich se později dostaneme.

K odpovědi se váže návratový kód uložený v položce VýslKód (RCode). Pouze pokud obsahuje nulu, vše proběhlo v pořádku a má smysl se zabývat dalšími položkami odpovědi. Jak DNS postupně košatělo, návratové kódy jsou jedním z míst, kde brzy začala tlačit bota. Do čtyř bitů, které jsou k dispozici, se vejde jen 16 hodnot. Rozšíření EDNS(0), kterému se za chvíli budeme věnovat, proto přidalo dalších 8 bitů v pseudozáznamu OPT, který doplňuje základní hlavičku. Přehled všech definovaných kódů včetně rozšiřujících najdete v tabulce 2.

Navzdory prodloužení návratového kódu stále platí, že ke stejnému výsledku mohou vést různé příčiny a hodily by se větší podrobnosti. RFC8914 extended DNS Errors prot přišlo s konceptem rozšířených chyb. Jedná se o dopňkovou informaci upřesňující, proč odpověď obsahuje daný návratový kód. Specifikace zakazuje měniť podle těchto informací chování DNS, jedná se skutečně jen o doplněk, který zejména pro diagnostiku problémů a ladění. Podrobnosti se dočtete dále.

Všechny čtyři hlavní sekce DNS zprávy mají proměnlivou velikost. Proto jsou předcházeny čtveřicí položek hlavičky obsahující jejích délky. Za nimi postupně následují:

Poslední dílek do skládačky datových formátů představují zdrojové záznamy, jimiž jsou naplněny závěrečné tři sekce DNS zprávy. Každý záznam obsahuje pět základních informací: jméno, k němuž se vztahuje, svůj typ, třídu, nesená data a dobu živostnosti této informace. Jsou přenášeny ve tvaru podle obrázku 3. Jméno (Name) je uloženo ve formátu popsaném v předchozí části. Samo v sobě obsahuje informace informace o délce, proto nejsou nutné žádné doprovodné položky. Přehled existujících Tříd (Class) podává tabulka. Definovaných Typů (Type) je dnes kolem devadesáti. Jejich výčet s veškerými podrobnostmi obsahuje část III na straně 369, postupem času se pozvolna mění — vznikají nové typy, jiné jsou opouštěny. Aktuální seznam tříd i typů IANA na adrese

http://www.iana.org/assignments/dns-parameters.

Doba životnosti (TTL) zdrojového záznamu je uvedena relativně. Tato položka obsahuje počet sekund, po které smí příjemce ponechat záznam ve vyrovnávací paměti. Je-li nulová, záznam se sice může použít, ale uložit jej nelze.

Nesená data mají proměnlivou strukturu i délku. Tu proto uvádí samostatná položka Délka dat (RDlength), jejímž obsahem je i délka položky Data (Rdata) v datech.

V obsahu zpráv se urputně bojuje o místo — 512 bajtů není nijak nijak oslnivé číslo, zejména pokud se do něj mají vejít i digitální podpisy a klíče DNSSEC. Jedním z významných spotřebitelů jsou jména, která se navíc často opakují. Proto RFC 1035 zavedlo jednoduchou komprimační metodu umožňující nahradit celé jméno či jeho část odkazem na jiné. Jedná se o šestnáctibitovou hodnotu, jejíž první dva bity obsahují jedničku a ve zbývajících čtrnácti je uloženo číslo bajtu v DNS zprávě, kde začíná odkazovaná jmenovka. Pokud se ve zprávě opakuje stejné jméno (například jména zdrojových záznamů v Odpovědi se zpravidla shodují se jménem Dotazu), lze je jednoduše nahradit odkazem. Dají se ale používat i částí jmen — odkázat se třeba na závěrečné dvě jmenovky — a odkazy kombinovat se jmenovkami — začít jméno normálně, ale konec nahradit odkazem. Jediným omezením odkazů je, že skončí vždy až koncem odkázaného jména. Nelze převzít první jmenovku a za ni doplnit něco jiného. Doménové jméno v DNS zprávě může tedy mít jednu z podob:

Komprimace je jednoduchá, výpočetně nenáročná, ale poměrně účinná, protože recyklovatelných jmen a jejich částí je v DNS zpávách dost. Extrémním příkladem je dotaz na kořenové servery. V odpovědi dostanete 13 jmen, která sdílejí poměrne dlouhou doménu root-servers.net. Vsekci Doplňky se každé jméno dvakrát opakuje v záznamech typu A a AAAA. V nekomprimované podobě by všechna jména v odpovědi zabrala 741 bajtů. Komprimace zmenší jejich objem na 116 bajtů, tedy méně než šestinu, Díky tomu celá odpověď včetně všech adres měří 811 bajtů.

Formát zprávy poskytuje dost malý prostor pro případné doplňky či rozšíření. Paul Vixie proto v roce 1999 přišel s návrhem, jak otevřít prostor těmto aktivitám. Vžilo se pro něj označení EDNS(0) a jeho definici přineslo RFC 2671 Extension Mechanism for DNS (EDNS0), později nahrazené stejnojmenným RFC 6891. Jedná se o stručný dokument, který vlastně definuje jen dva prvky: pseudozáznam OPT a rozšířené typy jmenovek.

Pseudozáznam OPT zvětšuje počet možných kódů pro výsledek operace z původních šestnácti na 4096, s čímž si snad DNS nějakou dobu vystačí, a umožňuje přidat další příznaky. Podstatný přínos spočívá také v tom, že ohlašuje velikost UDP dat, která je jeho odesílatel schopen zpracovat naráz, a umožňuje tak posílat odpovědi přesahující standard 512 bajtů.

Rozšířené typy jmenovek se poznají podle toho, že v nejvyšších dvou bitech svého prvního bajtu obsahují hodnotu 01. Zbývajících šest bitů pak obsahuje typ této rozšířené jmenovky a na jejich hodnotě nezáleží., jak budou interpretována její následující data. Žádné konkrétní rozšířené typy RFC 2671 nezavedlo, jen definovalo tento obecný mechanismus pro jejich vytváření. RFC 6891.

Na základní specifikaci navázalo RFC 2673 Binary Labels in the Domain Name System, které zavedlo binární jmenovky. Jejich formát byl jednoduchý — první bajt obsahoval konstatní hodnotu 65, identifikující tento typ jmenovky. Následovala jednobajtová délka a po ní až 256 bitů vlastní jmenovky v "nativní" podobě. Textový zápis binární jmenovky byl uzavřen do znaků \[ a ], vlastní jmenovka pak byla zapsána v binární podobě (prefix b), oktalové (prefix o) nebo hexadecimální (prefix x) soustavě, případně jako čtveřice tečkami oddělovaných desítkových čísel, stejně jako IPv4 adresa. Součástí zápisu jmenovky mohlo být i lomítko následované její délkou v bitech.

Binární jmenovky se ovšem neujaly. Chybějící podpora ze strany serverů způsobovala provozní potíže a žádný z návrhů na jejich konkrétní využití (například reverzní záznamy pro IPv6 podle pozděěji odmítnutého RFC 2874) se neprosadil. Když v roce 2013 vyšla v RFC 6891 aktualizovaná specifikace EDNS(0), nařídila povinnou podporu pseudozáznamu OPT, ovšem binární jmenovky uložila k ledu a změnila jejich statut na experimentální. Tato nová specifikace se k rozšířeným jmenovkám obecně staví velmi rezervovaně, protože způsobují řadu praktických problémů při nasazení.

EDNS(0) je podporováno snad všemi moderními implementacemo DNS. Staví na něm některá pozdější rozšíření, jako například DNSSEC, pro jehož objemné záznamy by původní maximální délka zprávy 512 bajtů byla příliš omezující.

Že je protokol DNS postaven na principu klient — server už víte. V běžných případech je komunikace mezi nimi triviální, zahrnuje výměnu pouhých dvou datagramů: klient pošle dotaz a server na něj odpoví. Nemá tudíž valný smysl řešit ztrácení paketů či přehození jejich pořadí, k němuž by při přenosu internetem mohlo dojít. Proto DNS jako standardní transportní protokol používá UDP, konkrétně jeho port 53.

Kromě základní komunikace však existují případy, kdy je objem přenášených dat větší. Tím nejčastějším je přenos zóny z primárního serveru na sekundární. Případně může celková velikost odpovědi překročit délkový limit (standardně 512 bajtů, při použití EDNS(0) protokolu může být vyšší, ale ani ten nemusí stačit). V takových případecj přijde ke slovu protokol TCP (opět port číslo 53). DNS je tedy jednou z mála služeb využívající oba základní trnasportní protokoly internetové architektury. Valnou většinu práce však zajistí UDP.

Situace s transportními protokoly se postupem času stále více zamotává a nově do ní vstupuje i šifrování. Zde popíšeme tradiční model, se kterým DNS přišlo na svět a který dosud převažuje. Specialitám, odchylkám a novotám se budeme věnovat později.

Už jsme zmínili, jak je důležité, aby všechny autoritativní servery poskytovaly o zóně konzistentní údaje. Jakmile se jejich odpovědi rozcházejí, vznikají dost matoucí a nepříjemně dohledatelné stavy, kdy z různých částí Internetu začínají přicházet hlášení "ono to nejde", zatímco správce si při zběžné kontrole snadno ověří, že "to funguje". Příčinou bývá, že různí klienti se obracejí na různé servery a dostávají odlišné odpovědi.

Existuje několi alternativ, jak zajistit synchronizaci dat mezi primárním a sekundárními servery. Lze využít prostředky zcela mimo DNS. Některé implementace například ukládají DNS data do databází. Potom lze použít standardní databázové nástroje pro replikaci dat a přenášet data na sekundární servery jejich pomocí. Pro textové zónové soubory je také k dispozici řada programů zajišťujících synchronizaci adresářů a souborů v nich — rsync, Unison a další.

Zde se ovšem budeme zabývat prostředky, které pro řešení tohoto problému nabízí samotné DNS. Jejich hlavní výhodou je snadnost použití. Nemusíte se starat o další službu, konfigurovat pro ni servery či nastavovat pravidla ve firewallech, vše obstará prostá DNS komunikace. Navíc zpravidla jen s minimálními zásahy do konfigurace.

Základní a nejjednodušší varianta funguje tak, že každý sekundární server se v určitých intervalech (jejich délku určuje hodnota Interval aktualizací v záznamu SOA příslušné domény) obrací na primární server a zjištuje, zda nedošlo v zóně ke změně. Provede to zcela jednoduše — standardním způsobem poptá záznam SOA a porovná jeho Sériové číslo s verzí, kterou disponuje. Pokud záznam SOA primárního serveru obsahuje vyšší hodnotu, zónová data se změnila a je třeba získat aktuální verzi.

V takovém případě se sekundární server opět obrátí na primární s DNS dotazem, tentokrát ovšem protokolem TCP, protože odpověď skoro jistě přesáhne rozsah jedné zprávy. Je tedy vhodnější použít transportní protokol, který zajistí spolehlivé doručení všech dat. Jako typ poptávaného záznamu ve svém dotazu uvede AXFR. Jedná se o speciální hodnotu, kterou tazatel požaduje kompletní zónu, jejíž jméno je uvedeno v dotazu. odpovědí bude celá séria zpráv, z nichž první a poslední obsahuje data pro vrchol příslušné zóny (její záznam SOA) a zprávy mezi nimi nesou všechny zdrojové záznamy, které do zóny patří. Podle opakovaného SOA v poslední zprávě příjemce pozná, že data jsou kompletní.

Tento způsob přenosu zóny definuje již původní RFC 1034, později byl upřesněn v RFC 5936 DNS Zone Transfer Protocol (AXFR). Teoreticky může proběhnout i mezi dvojicí sekundárních serverů — každý autoritativní server musí být schopen zodpovědět dotaz AXFR popsaným způsobem. V praxi se však až na naprosté výjimky přenáší zóna z primárního serveru na sekundární server.

Metod amá dvě nevýhody. Novinky se šíří pomalu, protože obvyklý interval pro kontrolu změn bývá několi hodin, během nichž se sekundární server o nic nestará a poskytuje svou verzi dat. Druhou nevýhodou je zbytečně velký objem dat. Přenáší se celá zóna, přestože do ní třeba přibyl jediný záznam. Odstranění obou nevýhod nabídla dvojice RFRC 1995 Incremental Zone Transfer in DNS a RFC 1996 A Mechanism for Promp Notification of Zone Changes (DNS NOTIFY), která přinesla přenos rozdílů v zóně a upozornění na změny.

Rozdílový přenos může sekundární server použít, když má k dispozici určitou verzi zónových dat a zjistil, že primární server má novější. Naváže TCP spojení a položí dotaz, ve kterém ovšem místo typu AXFR požaduje (pseudo)záznam IXFR. Do sekce Autorita svého dotazu vloží zázanm SOA té verze zóny, kterou má k dispozici. Jestliže primární server nepodporuje rozdílové přenosy, odpoví kompletní zónou obklopenou dvojicí aktuálních záznamů SOA, úplně stejně jako při odpovědi na AXFR. Pokud server podporuje rozdílové přenosy, bude odpověď také začínat a končit aktuální verzí záznamu SOA pro poptávanou zónu. Mezi nimi však nebude celá zóna, ale posloupnost změnových sekvencí. Každá změnová sekvence popisuje, jak je potřeba upravit zónu mezi svěma verzemi SOA. Má tvar:

Jestliže v některém záznamu dojde ke změně, projeví se jako smazání původního záznamu a přidání jeho nového znění.

Podívejme se na příklad. Řekněme, že sekundární server má verzi zóny nic.cz, jejíž SOA mese sériové číslo 0053. Na serverumezitím došlo ke dvěma navýšením sériového číla — ve verzi 0054 přibyl záznam typu A pro pc5 s adresou 10.1.2.3 a ve verzi 0055 došlo ke dvěma změnám: adresa pc1 byla změněna z 10.9.8.7 na 10.6.5.4 a pc5 se zóny zase zmizelo. Když sekundární server pošle dotaz na záznam typu IXFR doprovázený SOA se sériovým číslem 0053, dostal by odpověď vidíte na obrázku.

Tato data jsou zcela vyčerpávající a umožńují příjemci postupně rekonstruovat jednotlivé verze zóny. To ale většinou nebývá nutné, sekundární server jen potřebuje sestavit aktuální verzi. Odesílající server je proto oprávněn shrnout několik změn do jedné a popsat úpravu, která přesokčí několik generací a posune sérivé číslo o několik hodnot dál. V našem případě my mohl poslat jednu sekvenci, která změní verzi 0053 rovnou na 0055. Stroj pc5 z ní zcela vypadne, protože se objevil jen dočasně, verze 0053 ani 0055 jej neobsahují. Jediným rozdílem mezi nimi je změna adresy pc1.nic.cz. Odpověď by mohla vypadat tak, jak vidíte na dalším obrázku.

Je samozřejmě starostí primárního serveru, zda a jak si uchovává informace o jednotlivých verzích zónového souboru a změnách mezi nimi. Většina sekundárních serverů dnes poptává zónu pomocí IXFR a nechává na primárním, zda odpoví rozdílově či kompletním přenosem.

Pro rychlejší šíření změn zavedlo RFC 1996 mechanismus upozornění, jímž může primární server informovat ostatní, že v zóně došlo ke změně. Postup je jednoduchý, jakmile dojde k zásahu do zónových dat, primární server se postaví do role klienta a každému ze sekundárních serverů pošle DNS dotaz se speciální hodnotou OpKódu NOTIFY. Do sekce Dotaz vloží jméno zóny a jako požadovaný typ informace SOA.

Tímto způseobem předá sekundárnímu serveru informaci, že v zóně je cosi jinak. Oznámení o změně neposkytuje žádné podrobnosti, co se změnilo, jen prostou informaci, že došlo ke změne. Odpověď sekundárníh serveru na dotaz není podstatná, v zásadě jen potvrzuje, že informaci přijal. Následně by se měl chovat, jako by vypršel aktualizační interval — poptá se primárního serveru SOA a přenese si aktuální verzi zóny. Díky tomu získá sekundární server aktuální data prakticky okamžitě, jak byla změněna.

Celý proces aktualizací zónových dat je postaven na porovnávání sériových čísel v záznamech SOA. Jiná verze dat je rozpoznána podle odlišného sériového čísla. Zapomenete je při změně zvýšit a problém je za humny — sekundární servery si zachovají svou stávající verzi zóny a budou nerušeně poskytovat odpovědi odlišné od serveru primárního.

Existují dva jednoduché přístupy, jak volit hodnotu sériového čísla. Jeden je zcela minimalistický, kdy začnete od jedničky a pokračujete sekvenčně, v každé verzi hodnotu o jedničku zvětšíte. Podobný přístup jsme použili v našich zdejších příkladech. Obvyklejší a autoritami doporučované je vyjít v sériovém čísle z data, kdy došlo ke změně zóny. Číslo má pak tvar RRRRMMDDnn — prvních osm číslic obsahuje datum změny (rok, měsíc, den). Zbývající dvě číslice představují pořadové číslo změny v daný den. Dokážete tedy rozlišit sto změn denně, což bohatě stačí pro běžně spravované zóny. Jakmile byste povolili dynamické DNS a počítače si samy automaticky vkládaly své záznamy, stovka verzí denně zdaleka nemusí stačit. Pak by bylo lepší přejít na sekvenční číslování.

Za drobnou kuriozitu lze považovat, že existuje RFC 1982 definující aritmetiku pro práci se sériovými čísly.

Kompletní informace o obsahu zóny jsou všeobecně považovány za choulostivé a jejich poskytování komukoliv je považováno za bezpečnostní riziko. Není dramaticky vysoké, ale naprsotá otevřenost vůči požadavkům na zónové přenosy přinejmenším usnadňuje případnému útočníkovi zahlcení serveru. Odpověď AXFR server zatěžuje mnohem víc než běžné dotazy a pokud se na něj sesypou tisíce takových požadavků zároveň, nemusí to dopadnout dobře.

Bývá proto zvykem poskytovat zónové přenosy jen těm, kteří to opravdu potřebují — autoritativním serverům dané domény. Jednoduchou variantou je omezení IP adres, z nichž server přijímá tento typ požadavků. Pokud pro zónu neexistují tajné autoritativní servery, lze jednoduše povolit přenosy těm strojům, jež jsou v jejich záznamech NS. Tento způsob konfigurace podporuje většina implementací DNS serverů, u kterých se jedná o implicitní chování.

Jeho nevýhodou je, že falšovat adresu odesílatele paketu není nijak obtížné a adresy autoritativních serverů jsou v DNS volně k mání. Pro paranioky je k mání silnější alternativa, digitální podpis, kterým žadatel doprovodí svůj dotaz.

Dříve jsme se v textu zmínili o existenci žolíkových záznamů či možnosti určité libovůle v dotazech. Tyto prvky jsou obsaženy již v původní specifikaci DNS, nicméně jejich původní popis nechává určitý prostor čtenářově tvořivosti. Proto v roce 2006 (bezmála dvacet let později) vyšlo RFC 4592 The Role of Wildcards in the Domain Name System, které vše upřesňuje.

Základní myšlenkou je, že v zónách se mohou vyskytovat záznamy s universálním jménem, které mohou zastoupit libovolné neexistující jméno. Používá se pro ně označení žolíkové záznamy (wildcards records) a jako první jmenovku obsahují hvězdičku. Pokud klient poptává jméno, které sice neexistuje, ale příslušná doména obsahuje použitelný žolíkový záznam, dotázaný autoritativní server vytvoří záznam s hledaným jménem a vrátí tazateli jako úspěšnou odpověď. Důležité je, že žolíkové záznamy zastupují jen neexistující jména. Jakmile určité jméno existuje, žolíkový záznam na jeho úrovni (nebo vyšší) pro ně a jeho potomky nemá žádný účinek.

Tolik hrubý nástin a teď se podívejme na podrobnosti. Jednotlivé mechanismy si budeme ilustovat na konkrétních příkladech. Pro potřeby této sekce předpokládejme, že obsah zóny tul.cz je následující:

Odpovídající výřez doménového stromu znázorňuje obrázek, ve kterém vidíte kromě jednotlivých jmen i typy záznamů, které pro ně existují. Všimněte si, že hvězdička v posledních dvou záznamech představuje jednu a tutéž doménu.

RFC 4592 zavádí pojem hvězdičková jmenovka (asterisk label), což je jednoznaková jmenovka tvořená hvězdičkou. Žolíkové doménové jméno je jméno, jehož nejlevější jmenovkou je právě hvězdička. Například *.tul.cz je žolíkové jméno, zatímco www.*.tul.cz nikoli, protože hvězdičková jmenovka není v jeho nejlevější části. Poněkud to připomíná žolíkové znaky v názvech souborů či regulární výrazy. V porovnání s nimi jsou však možnosti žolíků v DNS velmi omezené — hvězdičku ve jmenovce nelze s ničím kombinovat a definovat tak třeba jména začínající na "a".

žolíkové záznamy zaskakují za neexistující jména. Ale kdy vlastně jméno existuje? Odpověď je jednoduchá: pokud pro ně existuje alespoň jeden zdrojový záznam nebo pokud má alespoň jednoho existujícího potomka. Takže v našem příkladu existuje doménové jméno ns.tul.cz, přestože se k němu neváže žádný záznam. Existuje však záznam typu A pro a.ns.tul.cz, tedy má existujícího potomka. Doména ns.tul.cz v našem příkladu představuje tak zvaný prázdný neterminál (empty non-terminal). Naproti tomu neexistují třeba jména www.tul.cz či www.obed.tul.cz.

Pojem nejbližší obsahující (closest encloser) je pro hledané jméno označeno takové existující jméno v doménovém stromě, která má s hledaným největší počet shodných jmenovek. A konečně zdroj syntézy (source of synthesis) pro hledané jména je žolíkové doménové jméno, které je přímým potomkem nejbližšího obsahujícího. Pochopitelně za předpokladu, že takové žolíkové jméno existuje. Prakticky řečeno: Pokud poptávané jméno neexistuje, postupně se z něj zleva odebírají jednotlivé jmenovky. Jakmile se dorazí k existujícímu jménu, byl nalezen nejbližší obsahující. K němu se doleva přidá hvězdičková jmenovka a pokud tento záznam existuje, jedná se o zdroj syntézy pro poptávané jméno.

Toto je důležitý princip. Při hledání použitelného žolíkového záznamu (zdroje syntézy) se nezkoumá, zda kdekoli výše v zóně existuje nějaký žolíkový záznam, jehož konec se shoduje s poptávaným jménem. Hledá se vždy právě na jednom místě: Vyhledá se nejbližší obsahující a pokud obsahuje jako přímého potomka hvězdičkovou jmenovku, máme zdroj syntézy. Jinak zdroj syntézy neexistuje.

Takže například pro robot.tul.cz bude nejbližším obsahujícím tul.cz a zdrojem syntézy *.tul.cz. Pro b.ns.tul.cz je nejbližším obsahujícím ns.tul.cz. Zdroj syntézy pro něj neexistuje, protože ns.tul.cz neobsahuje jako přímého potomky hvězdičku. Aby existoval, museli bychom do zóny přidat záznam pro *.ns.tul.cz:. Existence záznamu *.tul.cz zde nemá žádný vliv, protože hvězdička není potomkem nejbližšího obsahujícího jména, do doménového stromu je zapojena výše.

Zbytek je popsán v bodě 3c algoritmu pro činnost serveru. Dorazí-li dotaz na neexistující jméno, vyhledá se pro něj zdroj syntézy. Pokud existuje, nahradí se hvězdičková jmenovka příslušnou částí hledaného jména a výsledný záznam se vloží do odpovědi. V opačném případě bude odpovědí chyba "neexistující doména". Podívejme se na pár příkladů.

Dotaz: Záznam MX pro www.tul.cz.

Odpověď: NoError, sekce Odpověď obsahuje

Poptávané jméno neexistuje, nejbližší obsahující je tul.cz. Zdrojem syntém je *.tul.cz a pro něj existuje záznam typu MX. Dojde k aplikaci tohoto žolíkového záznamu, která povede k uvedené odpovědi.

Dotaz: Záznam A pro www.tul.cz.

Odpověď: NoError, sekce Odpověď je prázdná.

Zdraj syntézy je stejný jako v předchozím příkladě, ovšem neexistuje pro něj záznam typu A. Odpověď proto bude prázdná — jméno "existuje" (přesněji řečeno existuje žolíkový záznam, který je vytvoří), ale není pro něj k dispozici poptávaný typ záznamu.

Dotaz: Zázanm A pro www.obed.tul.cz.

Odpověď: NoError, sekce Odpověď je prázdná.

Zdrojem syntézy je opět *.tul.cz, pro který neexistuje záznam typu A. Na první pohled by se mohlo zdát, že zafunguje "přesnější" záznam www.*.tul.cz, ale pokud jste v textu výše nepřeskakovali, víte, že to není žolíkový záznam a nemůže se z něj cokoli generovat.

Dotaz: Záznam MX pro www.obed.tul.cz.

Odpověď: NoError, sekce Odpověď obsahuje

Zdroj syntézy je stále stejný: *.tul.cz. Hvězdička tentokrát bude nahrazena dvojicí www.obed. Jelikož jedna hvězdička poskytuje libovolně dlouhý řetězec jmenovek, nemá valný smysl vkládat do zóny žolíkový záznam *.*.tul.cz. Druhá hvězdička v něm nefunguje jako žolík a na dotat z příkladu se nevztahuje.

Dotaz: Záznam MX pro cosi.tul.cz.

Odpověď: NoError, sekce Odpověď je prázdná.

Poptávané doménové jméno existuje, k uplatnění žolíkových záznamů prot vůbec nedojde (postupuje se podle bodu 3a). Jelikož pro cosi.tul.cz neexistuje záznam typu MX, odpověď bude prázdná. Žolíkovými záznamy nelze doplnit informaci pro všechny, jako například universální záznam MX pro celou doménu. Uplatní se jen pro neexistující jména.

Dotaz: Záznam MX pro muj.*.tul.cz.

*Odpověď: * NXdomain

Jelikož existuje doménové jméno *.tul.cz, je toto jméno nejbližším obsahujícím a pro dotazované jméno neexistuje zdroj syntézy. Tím by byl žolíkový záznam *.*.tul.cz, který však v zóně není. Odpovědí proto bude chyba "neexistující doména".

Žolíková jmenovka se může vyskytnout i v dotazu, jak jste viděli v posledním příkladu, jak jste viděli v posledním příkladu. V tom případě ale nepředstavuje obecný dotaz "pošli mi všechny záznamy", ale cílený dotaz "pošli mi tento žolíkový záznam". Zpracování odpovědi nevyžaduje žádné speciální kroky, vyhoví mu pouze záznam s žolíkovým jménem shodným se jménem v dotazu. Pokud by tedy v našem příkladu dorazil dotaz na záznam typu A pro *ns.tul.cz, odpovědí by byl chybový kód ohlašující neexistující doménu. Naopak dotaz pro záznam A pro www.*.tul.cz by skončil úspěšnou odpovědí:

Dodejme, že žolíkové záznamy se v něm nijak neuplatnily, protože jméno www.*.tul.cz existuje.

Stejně tak nemá žolíkové jméno žádný speciální význam, pokud se objeví v datech záznamu. Server je prostě odešle beze změny tazateli. Tyto dva případy — dotaz obsahující hvězdičkovou jmenovku nebo její nepřítomnost v datové části záznamu — jsou jediné, kdy se hvězdička objeví v odpovědi. Dojde-li k použití žolíkového záznamu, je hvězdička z něj nahrazena tak, aby odpověď obsahovala poptávané jméno.

Tolik k principům fungování žolíkových záznamů. Jejich prostřednictvím lze opravovat překlepy v doménových jménech a například směrovat všechny WWW požadavky adresované neexistujícím strojům na centrální server. Takový přístup ale spíše nedoporučujeme. Dobrým příkladem může být pokus společnosti VeriSign zavést toto chování v doménách com a net. 15. září 2003 do nich vložila žolíkové záznamy, které zavedly návštěvníky neexistujících domén druhé úrovně na jejich servery. Tento krok vzbudil obrovskou nevoli a po necelých třech týdnech byl "dočasně odvolán". Vypadá to, že jednotkou dočasnosti bude u nás dobře známý 1 furt. Podrobně se dočtete na adrese:

http://www.icann.org/en/topics/wildcard-history.html

Napravovat uživatelské či autorské chyby na straně DNS serveru je krajně problematické. Mají ošklivou tendenci kvasit pod povrchem a později vyhřeznout na povrch s horšími důsledky, než kdyby se hned na začátku opravily. Pokud nemáte velmi specifické potřeby, doporučujeme držet se od žolíkových záznamů co nejdál.

Vyrovnávací paměť hraje hlavní roli ve zvyšování efektivity DNS a zrychlování jeho odezev. Nejvýznamější jsou samozřejmě sdílené paměti poskytované lokálními rekurzivními servery v jednotlivých sítích, na nichž se schází místní klienti.

Každý záznam má přidělenou životnost (TTL, Time to Live) omezující dobu jeho možnosti uložení. V odpovědích se její hodnota přenáší jako počet sekund, které zbývají do vypršení doby platnosti daného záznamu. Po uložení do vyrovnávací paměti by měla být životnost každou sekundu snižována o jedničku a pokud tím dojde k jejímu vynulování, záznam se odstraní. V praxi servery řeší životnost záznamů zpravidla méně zatěžujícím způsobem, který nevyžaduje pravidelné průchody vyrovnávací pamětí. Například převodem na absolutní čas, který u každého uloženého záznamu říká, kdy jeho platnost vyprší.

Pokud server odesílá neautoritativní odpověď (tedy přeposílá dříve získané záznamy), přidělí jejím záznamům životnost, která jim podle aktuálního stavu vyrovnávací paměti zbývá. Pokud například posílá záznam, který získal před hodinou a tehdy měl životnost 4 hodiny, odešle je s tříhodinovou životností.

Nulovou životností lze zakázat uložení záznamů do vyrovnávací paměti. Dorazí-li odpověď s životností rovnou nule, znamená to, že je použitelná pouze pro dotaz, na nějž odpovídá. Příjemce si ho nesmí uložit do vyrovnávací paměti a používat pro jiné dotazy.

Postupem času se rozšířila praxe využívat do určité míry i prošlé záznamy. Stává se totiž, že autoritativní servery domény jsou po určitou dobu nedostupné, například když se staly cílem útoku. Dostane-li rekurzivní server dotaz, na který má uloženou odpověď s prošlou životností, musí se obrátit na autoritativní servery příslušné domény a pokusit se ji zaktualizovat. Pokud vše proběhne normálně, uloží si nově získanou odpověď s novou životností a pokračuje jako obvykle.

Jestliže ale žádná odpověď nedorazí, může tazateli poslat novou uloženou odpověď s prošlou životností podle hesla "lepší prošlá než žádná". Pravděpodobnost, že se v datech nic nezměnilo a odpověď stále platí, je poměrně vysoká. Nastaví jí nenulové, ale krátké TTL (doporučeno je 30 s). Současné implementace DNS serverů většinou umožňují takové chování nastavit. Oficiálně je připustilo RFC 8767 Serving Stale Data to Improve DNS Resiliency.

Skutečnost, že záznamy se posílají v sadách, ale životnost má každý z nich vlastní, otevírá prostor pro určité nesrovnalosti. Co když dorazí pro hledané jméno tři záznamy typu A s různou životností? To by znamenalo, že některé vyprší dříve s do vypršení zbývajících by vyrovnávací paměť poskytovala nekompletní informace — jedne nebo dva záznamy ze tří existujících. Mechanismy DNS se proti vzniku těchto nekonzistencí brání dvěma požadavky:

Zajímavou kapitolou představuje také ukládání záporných odpovědí — tedy chyb ohlašujících neexistující doménu nebo prázdných odpovědí, které znamenají nepřítomnost požadovaného typu záznamu. RFC 1034 zavedlo toto chování jako nepovinné, navíc s omezením, že záporné dopovědi slouží jen pro vlastní potřebu, ale nelze je neautoritativně posílat dál. Praxe však ukázala, že ukládání a přeposílání záporných odpovědí citelně přispívá ke zrychlení činnosti DNS. Proto v roce 1998 vyšlo RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) s novou definicí tohoto mechanismu.

Podle něj se negativní odpovědi ukládají do vyrovnávací paměti stejně jako odpovědi kladné a stejně se přeposílají dál. Je tu však drobný zádrhel s životností. Záporná odpověď nemá v sekci Odpověď žádný záznam, který by určoval, jak dlouho ji uložit. Problém se řeší obchvatem. Když autoritativní server posílá zápornou odpověď, musí do sekce Autorita vložit záznam typu SOA pro odpovídající zónu. Právě životnost tohoto záznamu bude použita jako životnost záporné dopovědi ve vyrovnávací paměti. Teké při přeposílání záporné odpovědi z vyrovnávací paměti odesílající server musí přibalit uložený záznam SOA s příslušně upravenou hodnotou TTL. U záporných odpovědí, jež nejsou doprovázeny záznamem SOA, nelze určit životnost, protby neměly být ukládány.

K dalšímu upřesnění pravidel ohledně negativních odpovědí došlo v RFC 8020 NXDOMAIN: There Really Is Nothing Underneath. Zdůrazňuje se v něm, že je třeba rozlišovat prázdné odpovědi (s výsledkovým kódem NoError a prázdnou sekcí Odpověď) a odpovědi s výsledkovým kódem NXDoomain, které oznamují neexistenci daného jména a čehokoli pod ním.

Prázdná odpověď znamená, že doménové jméno existuje, ale DNS pro ně neobsahuje záznam poptávaného typu. Možná pro ně dokonce neexistuje vůbec žádný zdrojový záznam, ale existuje nějaký jeho potomek. Prázdné odpovědi se ukládají do vyrovnávací paměti s výše uvedenou životností a dále se s nimi zachází stejně jako s uloženými pozitivními odpověďmi.

Odpověď NXDomain naproti tomu signalizuje neexistenci daného uzlu i čehokoliv pod ním v doménovém stromě. RFC 8020 doporučuje tyto negativní odpovědi ukládat do vyrovnávací paměti aposílat v odpovědích, kdykoli dorazí dotaz na jméno z podstromu jimi začínajícího. Pokud je například z dřívějšího řešení uložena ve vyrovnávací paměti odpověď NXDomain pro cosi.tul.cz a rekurzivní server dostane dotaz na záznamy typu A pro www.kdesi.cosi.tul.cz, nebude se nikde na nic ptát a rovnou odpoví, že doménové jméno neexistuje (NXDomain).

Ještě intenzivněji se s informací o chybějících záznamech může pracovat, pokud je doména podepsána pomocí DNSSEC. Pak totiž tazatel dostane elektronicky podepsanou informaci o tom, jaké typy záznamů existují pro poptávané jméno a rozsah jmen, mezi nimiž žádné jiné není. Tyto údaje může po dobu jejich životnosti využívat a generovat z nich záporné odpovědi.

Jednotlivé resolvery se pochopitelně významně liší v závislosti na operačním systému (či obecné platformě, protože DNS klienta obsahují i hardwarová zařízení) a velmi se liší i způsoby jejich konfigurace. Ta může obsahovat různé jemnůstky ^[2], důležité jsou však dva údaje:

Dobrou zprávou je, že pokud je stroj konfigurován automaticky protokolem DHCP, zpravidla jeho konfigurace zahrnuje i DNS. Většinou tedy nemusíte nad ničím příliš hloubat a DNS jednoduše funguje oblíbeným způsobem plug and play. Informace zde uvedené vám v takovém případě poslouží ke kontrole, jak je systém ve vašem případě nastaven.

Podívejme se teď, jak si prohlédnout, případně změnit konfiguraci DNS resolveru v nejznámějších operačních systémech.

V druhé části této kapitoly se podrobněji podíváme na nejznámější programy, které uživateli umožňují klást DNS dotazy a zobrazovat zjištěné výsledky.

Opakovaně jsme se zmínili o relativních doménových jménem. Jejich použití v zónových souborech je jednoduché a jednoznačné — nekončí-li jméno v zónovém souboru tečkou, připojí se za ně aktuální doména (lze změnit direktivou $ORIGIN).

V koncovém resolveru v operačním systému se uplatňuje podobně jednoduchá myšlenka. Pokud dostane k řešení relativní jméno (například když uživatel zadal webovému prohlížeči jako cílovou adresu jen www nebo spustil z příkazového řádku ssh server), připojuje za ně postupně jednotlivé domény k prohledávání podle své konfigurace a v DNS hledá takto sestavená jména. Komplikace se skrývají v detailech, je třeba zodpovědět dvě otázky:

Odpověď sice existuje, ale prodělala určitý historický vývoj a ne každý operační systém se drží aktuální verze. Reálné chování resolveru bohužel závisí na konkrétním prostředí. Přístupy jednotlivých systémů podrobně zkoumal Geoff Huston a výsledky publikoval ve svém článku, ze kterého nyní vycházíme.

Podle původních představ autorů DNS se při běžném používání měla basolutní jména rozlišovat od relativních stejně jako v zónových souborech — tečkou na konci. Podle RFC 1034 jméno končící tečkou je absolutní a klient je při dotazování nebude nijak měnit. Jestliže jméno tečkou nekončí, považuje se za relativní a připojí se za ně místní domény (resp. doména nastavená jako prohledávaná).

V praxi se tato představa neuchytila. Přítomnost/nepřítomnost tečky na konci jména je příliš nenápadná, uživatelé jsou roztržití a líní. Proto se programy využívající DNS resolver snažily uplatňovat různé heuristiky a považovat za absolutní i řadu jmen bez tečky. Obvyklým indikátorem byla složitost zadaného jména, tedy počet jeho jmenovek.

Tuto běžnou praxi kodifikovalo RFC 1123 a doporučilo, aby jméno poptávané v DNS obsahovalo vždy alespoň tři jmenovky.^[4] Takové jméno by mělo být považováno za absolutní, i když nekončí tečkou. Naproti tomu jméno s menším počtem jmenovak, které nekončí tečkou, bude chápáno jako relativní. RFC 1536 tento princip ještě zjednodušilo — relativní je jen jméno neobsahující tečku. Jakmile jméno končí tečkou, nebo je rozděleno na dvě či více jmenovek, má být považováno za absolutní. Tento přístup převzalo i RFC 3397, které představuje zatím poslední slovo v této oblasti. Podle něj by se resolver měl chovat následovně:

Šedivá je teorie, praxe si ovšem žije po svém. Ilustruje to tabulka, jejíž data vycházejí z článku [4]. Najdete v ní dotazy, které položí resolvery jednotlivých operačních systémů, když dostanou k řešení jména www (s tečkou na konci), www (bez tečky) a www.ns (bez tečky na konci), když mají jako prohledávanou doménu nastaveno nic.cz.

Jak vidíte, podle doporučení se chovají jen MS Windows XP. Počínaje verzí Vista už Microsoft opustil připojování prohledávané domény, pokud poptávané jméno obsahuje tečku a dotaz na ně byl neúspěšný. Stejně se chová i OS X. Systémy odvozené z Unixu jdou nad rámec RFC 3397 a dotáží se i na samotné jméno s jedinou jmenovkou, pokud neuspěl předchozí dotaz s přidanou prohledávanou doménou.

Aby situace byla ještě veselejší, zasahují do DNS jmen i konkrétní aplikace, zpravidla ve snaze usnadnit uživateli život a opravovat běžné chyby. Geof Juston ve zmiňovaném článku testoval webové prohlížeče a zjistil, že jsou velmi kreativní. Složení DNS dotazu ve stejném systému při stejném vstupním jméně ses znatelně lišilo v závislosti na tom, který konkrétní prohlížeč byl použit.

Co z toho plyne? Stručně řečeno, na relativně zadáváná jména není spolehnutí. Pokud se vůbec rozhodnete používat prohledávanou doménu a nastavovat ji svým místním strojům (obvykle prostřednictvím DHCP), raději se omezte jen na jednu. čím delší bude seznam prohledávaných domén, tím bizardnější výsledky lze očekávat.

V principu je možné, aby aplikace nevyužívala systémový resolver a veškerou DNS komunikaci si obstarávala sama. Může si otevřít UDP port, sama formulovat DNS dotazy, přijímat a analyzovat odpovědi. Tento postup se ale nedá doporučit. Nabízí v podstatě jen dvě výhody

Zato nevýhod je celá řada:

S trochou kreativity by se dalo pokračovat, ale nemá to valný smysl. Řešit si DNS "na koleně" v rámci aplikace obecně není dobrý nápad a dlouho to nikdo nedělal. Smysl by mohlo mít snad jen při mimořádných nárocích dané aplikace.

Existuje ovšem aktivita z této oblast, která smysl má. Google přišel se službou, která poskytuje přístup k jeho veřejným rekurzivním serverům protokolem HTTPS. Původně ji pojmenoval DNS over HTTPS, později byl ale tento název použit pro standardní přenosový protokol. a služba se jmenuje JSON API for DNS over HTTPS. Hlevní motivace je bezpečnost — komunikace klienta s rekurzivním serverem je šifrována, takže je chráněna proti podvrhování odpovědí a zároveň zachovává soukromí.

Využití se očekává především ze strany weboivých aplikací. Prohlížeč umí HTTPS, takže není třeba vymýšlet nic nového. rozhraní je navíc velmi jenoduché. Služba je k dispozici na adrese https://dns.google.com/resolve?

Dotazy se posílají metodou GET a poptávaná data se kódují do URL v podobě několika parametrů. Nejdůležitější je name (poptávané doménové jméno) a type (typ záznamu). Například dotaz na IPv6 adresu serveru www.nic.cz by vypadal takto:

https://dns.google.com/resolve?name=www.nic.cz&type=aaaa

Odpovědi přicházejí ve formátu JSON, jehož jednotlivé položky odpovídají součástem DNS zprávy.^[5] Ty části, které mohou obsahovat více záznamů se řeší polem. Konkrétně odpověď ba výše uvedený dotaz obsahuje:

Všimněte si, že většina z výše uvedených nevýhod zde neplatí. Je to dáno tím, že aplikace si ve skutečnosti neřeší DNS sama, spíše používá alternativní API — místo volání lokálního resolveru používá prostřednictvím HTTPS resolver vzdálený. Krkolomnosti ponechá na něm, sama si interpretuje výsledky. Konfigurace není potřeba, je dána adresou této služby. V podstatě zůstává jediný vážný problém — chování DNS nemusí být konzistentní s aplikacemi využívajícími lokální resolver. Ovšem právě kvůli potenciálnímu omezení lokálního resolveru (např. chybějící podpoře DNSSEC) se tato služba využívá.

Podrobnější popis najdete na adrese:

https://developers.google.com/speed/public-dns/docs/doh/json

Jak jsme již naznačili, služba Google byla první vlaštovkou při koketování s HTTPS. Později byl standardizován protokol DNS over HTTPS (DoH), který používá HTTPS jen jako komunikační kanál a posílá po něm standardní zprávy. Tím se ovšem otevřely dveře k řešení DNS přímo z aplikací dokořán.

Jádro DNS je jako dělané pro použití UDP. Transakci tvoří výměna dvou krátkých paketů: dotaz a odpověď. Zatímco TCP by ještě navazoval spojení, UDP už má hotovo. Další dotaz bude pravděpodobně kladen jinému serveru, není tedy důvod udržovat spojení. Spolehlivost není třeba řešit v transportní vrstvě. Když klient nedostane včas odpověď, jednoduše se zeptá znovu, pokud možno jiného serveru.

Návrh DNS proto počítal s UDP jako se základním protokolem. Tazatel podle RFC 1035 vždy nejprve poslel dotaz po UDP a jen když dorazila odpověď s příznakem zkrácení TC, navázal jednorázově TCP spojení se stejným serverem, dotaz v něm zopakoval, přijal kompletní odpověď a spojení zase ukončil. Výjimkou z tohoto obecného principu představovaly zónové přenosy, kde se rovnou navazovalo TCP spojení, protože celá zóna se do jednoho paketu obvykle nevejde.

Původně se počítalo s maximální velikostí zpráv 512 bajtů, pozdější rozšiřující mechanismus EDNS(0) umožnil přenášet po UDP i delší zprávy. Je to jednoduché a efektivní. Bohužel také choulostivé. Protokolem UDP může kdykoli odkudkoli dorazit paket a sever nemá od tazatele žádnou zpětnou vazbu, nemůže si být jist, že paket spolehlivě odeslal ten, kdo je uveden ve zdrojové adrese.

To činí z UDP lákavý cíl pro různé švindly. Nejvážnější jsou nepochybně zesilované útoky, kdy se díky falešné zdrojové adrese a volbě takových dotazů, na které přicházejí co největší odpovědi, sesypena oběť hromada DNS zpráv a zahltí cílový stroj nebo síť k němu vedoucí.

Druhý problém UDP také souvisí s rostoucí velikostí paketů. Je jím fragmentace, tedy rozdělení příliš dlouhého paketu, který daná linka nedokáže přenést najednou, na několik menších. Nejdená se o nic specifického pro DNS nebo UDP, fragmentace je součástí IP a je s námi už od jeho počátků. Podívejme se nejprve, jak funguje. Později vysvětlíme, v čem je problematická a proč se jí snažíme vyhýbat.

Příčinou fragmentace je skutečnost, že v Internetu se používají různé technologie, které dokáží přepravovat různě velké pakety. V IP se pro tento limit používá termín MTU — Maximum Transmission Unit. Například Wifi pojme do jednoho rámce až 2304 B dat, zatímco Ethernet nanejvýš 1500 B. Pokud byste po Wifi odeslali 2000 B dlouhý paket a ten by dorazil do místa, kde podle směrovací tabulky má pokračovat po Ethernetu, vznikne problém: prostě se do odchozí linky nevejde. Pro tyto případy je určena fragmentace. Datagram se rozdělí na několik menších, které se přenesou samostatně a příjemce si je poskládá do původní podoby.

Aby bylo možné fragment opět složit, nese v sobě trojici informací:

Datagram vždy skládá až příjemce. Dá si dohromady všechny fragmenty se stejným identifikátorem, seřadí jejich data podle posunů a pokud má vše od začátku až po fragment, jehož příznak oznamuje, že žádný další za ním už nenásleduje, podařilo se mu rekonstruovat původní dlouhý datagram.

Detaily se liší v závislosti na verzi internetového protokolu. V IPv4 jsou fragmentační údaje součástí základní hlavičky a fragmentovat zde může kterýkoli stroj na cestě od odesílatele k příjemci. IPv6 se snaží fragmentaci omezovat, fragmentovat zde může pouze odesílatel. Jestliže se po cestě datagram nevejde do odchozí linky, inkriminovaný stroj jej zahodí a pošle odesílateli ICMPv6 zprávu oznamující tuto událost a MTU linky, které zahození způsobilo. Odesílatel pak bude datagram odpovídajícím způsobem fragmentovat, nebo rovnou pošl kratší datagram. Jelikož je fragmentace v IPv6 spíše vzácná, byly její údaje přesunuty ze základní hlavičky do jednoúčelové rozšiřující hlavičky nazvané Fragmentace.

Zní to logicky, takže v čem je problém? Stručně řečeno v tom, že Internet je protkán prvky, které se chovají nestandardně. V důsledku toho framentace způsobuje řadu problémů. Například firewally při posuzování přípustnosti datagramu často pracují s údaji z hlavičky transportního protoklu, zejména s čísly portů. Touto hlavičkou začínají nesená data, je proto k dispozici pouze prvním fragmentu. Nejsou vzácné situace,kdy komunikace nefunguje, protože firewall po cestě zahazuje všechny pokračovací fragmenty. Podobné problémy mohou způsobovat prvky pro rozkládání zátěže nebo NATy. Celkem běžně se dnes blokuje ICMP, klíčový zdroj informací pro fragmentaci v IPv6.

Důsledkem je, že fragmentace významně snižuje spolehlivost přepravy. Podle některých měření v RFC 7872 jen dva ze tří fragmentovaných IPv6 datagramů dorazí úspěšně do cíle. Proto se snažíme, aby k fragmentaci pokud možno nedocházelo. Jenže při použití UDP a povolení velkých odpovědí pomocí EDNS(0) jsou šance vyhnout se jí jen omezené.

Popsané problémy UDP jsou jedním z rostoucích zájmů o TCP. Při jeho použití zesilovaný útok není možný, protože se před odesláním jakýchkoliv dat nejprve navazuje pojení. Dorazí-li serveru žádost o navázání spojení z falešné adresy, reaguje na ni vstřícně. Jenže jeho odpověď dorazí k cíli útoku, který o spojení nežádal a jeho navazování okamžitě zruší, aniž by se přenášely jakékoli DNS zprávy.

Také fragmentace je v TCP ošetřena. Povinně obsahuje mechanismus objevování cesty podle RFC 1191, resp. RFC 1981. Snaží se o co největší velikost datagramů, které projdou k příjemci bez fragmentace, Dělá to tak, že oděšle datagram o velikosti MTU odchozího rozhraní (v IPv4 navíc zakáže fragmentaci). Dorazí-li ICMP zpráva ohlašující jeho zahození, zmenší velikost podle údaje z ní a opakuje pokus. Podobně se chová i v případě, že nedojde zpráva ani odpověď. V tom případě zkrácení odhadne. Pokračuje, dokud nedorazí odpověď od adresáta. Tím zjistí velikost, která prochází celou trasou bez fragmentace. Té se následně bude držet (a v IPv4 stále všem datagramům zakazovat fragmentaci).

Důsledkem postupně rostoucího významu TCP pro DNS je i RFC 7766 DNS Transport over TCP — Implementation Requirements, které mimo jiné deklaruje podporu TCP jako povinnou. Zároveň umožňuje jeho okamžité použití. Tezatel už nemusí nejprve poslat svůj dotaz po UDP, ale je čistě na jeho uvážení jaký protkol použije.

Navazovat TCP spojení pro jediný dotaz není zrovna ideálem efektivity. Proto je v RFC 7766 věnována značná část trvalým (persistentním) spojením, kdy je jedno TCP spojení využito pro větší počet dotazů. To bude zajímavé zejména v případech, kdy klient očekává, že se jeho komunikace neomezí na jediný dotaz. Typickým příkladem je koncový resolver a jeho místní rekurzivní server, na nějž se obrací se všemi svými DNS dotazy.

Aby bylo spojení využito co nejefektivněji, klient nemusí čekat na odpověď a může daným spojením posílet jeden dotaz za druhým. Analogicky server není vázán pořadím dotazů a posílá odpovědi, jakmile má data k dispozici. Pokud tedy řešení některého dotazu trvá déle, může se stát, že odpověď na pozdější dotaz pošle dříve, například ze své vyrovnávací paměti. Musí ale odpověď poslat vždy stejnou cestou, kterou dorazil dotaz. Pokud například má otevřeno TCP spojení a ze stejné IP adresy mu dorazí dotaz protokolem UDP, musí na něj odpovědět po UDP a nesmívyužít existující TCP spojení.

Párování odpovědí a dotazů na straně klienta probíhá výlučně podle jejich Identifikátorů, pořadí zpráv nehraje roli. Proto klient nesmí po stejném spojení zopakovat stejný Identifikátor.

Otevřená TCP spojení server samozřejmě zatěžují, proto by měl klient jejich počet udržovat na minimu, typicky jedno k danému serveru. Server je oprávněn omezit počet současně otevřených spojení ze stejnéadresy, ovšem neměl by to dělat příliš restriktivně, protože za jednou adresou NATu se může skrývat větší počet klientů. Jako ochrana před přetížením v případě serveru spíše připadá v úvahu zavírání existujících pojení. RFC 7766 doporučuje dělat to, pokud spojení během dvou minut nevykazuje žádnou aktivitu.

Trvalás pojení jsou poměrně nová a ne každý program pro DNS je podporuje. Aby se obě strany mohly dohodnout na jejich použití, zavedlo RFC 7828 The edns-tcp-keepalive EDNS0 Option potřebnou signalizaci — volbu edns-tcp-keepalive pro EDNS(0). Pokud ji klient vloží do svého dotazu (smí se přidávat jen k dotazům zaslaným protokolem TCP), dává najevo, že by rád zachoval spojení otevřené.

Server podporující trvalá spojení pak ve své odpovědi prostřednictvím této volby oznámí limit pro dobu nečinnosti daného spojení ve stovkách milisekund. Pokud klient během této doby nepoloží žádný další dotaz, měl by spojení zavřít. Server samozřejmě dobu nečinnosti určuje podle svého vytížení a může ji v dalších dotazech měnit v závislosti na aktuální situaci. Může ohlásit i nulu, což je výzva klientovi, aby spojení co nejrychleji uzavřel. Kromě toho samozřejmě každá ze stran může TCP spojení kdykoli uzavřít, pokud to potřebuje.

Provoznímio záležitostmi přenosu DNS po TCP se zabývá RFC 9210 DNS Transport over TCP — Operational Requirements, které je zárověň doporučením BCP 235. Obsahuje především shrnutí problematiky a korekce několika starších RFC, která brala TCP jako doplňkový protokol. Zajímavá je příloha A, kde najdete přehled všech RFC relevantních pro tuto problematiku.

Dlouhodobá spojení otevřela pro DNS nové možnosti. Dosud aktivita vycházela výlučně ze strany klienta, protože server nevěděl, kdy se na něj kdo obrátí s jakým dotazem. Jestliže je ale klient trvale připojen, mohl by i server aktivně zasáhnout do konverzace — například upravit parametry spojení nebo ohlásit změnu, ke které u něj došlo.

Základní rámec pro takovou komunikaci zavedlo RFC 8490 a pojmenovalo ji stavový provoz DNS (DNS Stateful Operations, DSO). Nejedná se o náhradu klasického DNS, ale o jeho možný doplněk. Hlavní novinko DSO je, že umožňuje dlouhodobé operace, aby se klient třeba přihlásit k odběru novinek v zóně.

Předpokladem pro použití DSO je dlouhodobé spojení obou stran zachovávají pořadí, jako je DNS po TCP nebo TLS. Tímto spojením si komunikující strany budou vyměňovat standardní DNS zprávy jako dříve, ale vedle nich si mohou posílat i zprávy protokolu DSO.

Jejich formát vychází z DNS zpráv a poznají se podle OpKódu s hodnotou 6. Neobsahují žádné zaznamy, proto jsou délky všech čtyř částí zprávy nulové. Místo toho přenášejí data v jednotkách označovaných typ—​délka—​hodnota (Type—​Length—​Value, TLV), ze kterých si poskládají tělo zprávy podle potřeby. První TLV je primární a určuje význam zprávy. Za ním mohou následovat doplňková TLV s dodatečnými imformacemi.

DSO počítá jak s tradičním komunikačním schématem požadavek — odpověď, tak s jednosměrnými zprávami, která druhá strana přijme, ale nijak na ně nereaguje. Komunikační kanál zaručuje soplehlivý přenos, na úrovni DNS proto není třeba zprávy potvrzovat.

Po navázání spojení se klient pokusí vytvořit takzvanou DSO seanci (DSO session). Jednoduše pošle libovolný DSO požadavek a dostane-li na něj úspěšnou odpověď, znamená to, že i server podporuje DSO a seance byla vytvořena. V opačném případě musí vzít na vědomí, že server DSO neumí, a přestat je používat. Jednosměrné DSO zprávy lze posílat až po vytvoření seance.

Základní specifikace definuje jen tři TLV:

Časové intervaly určují míru trpělivosti při využívání spojení. Jejich prostřednictvím lze upravit rovnováhu mezi zpožděním při navazování nového spojení a zátěží serveru způsobenou uchováváním nevyužívaného spojení. Jsou dva:

Popsaný mechanismus intervalů má přenost před výše popsanou volbou edns-tcp-keepalive. Je-li ba spojení provozováno DSO, nebere se na edns-tcp-keepalive ohled.

DSO samo o sobě mnoho nového nepřináší, ale dají se na něm postavit zajímavé služby.

U prostého TCP se ale vývoj přenosového protkolu pro DNS nezastavil. Po Snowdenově odhalení masivních pasivních odposlechů datových komunikací se v Internetu začala velká pozornost věnovat ochraně soukromí a šifrování přenášených dat. DNS není výjimkou. IETF pro tuto problematiku založilo pracovní skupinu DNS PRIVate Exchange aneb dprive.

Skupina dprive se nejprve věnovala komunikaci mezi koncovým strojem a rekurzivním resolverem. Po vytvoření protokolů pro tento účel se začala orientovat na zabezpečení komunikace mezi rekurzivním resolverem a autoritativními servery. Řešení pro tuto část DNS světa ale teprve vznikají.

V polovině roku 2023 máme k dispozici několik alternativ pro šifrování prvního kroku, tedy přenosu mezi koncovým strojem a rekurzivním resolverem, který řeší jeho dotazy. DNS lze ochránit pomocí TLS, DTLS, HTTPS nebo QUIC. Nejprve se podívejme na společné vlastnosti všech těchto variant.

Všechny vytvářejí šifrovaný tunel, který znemožňuje odposlech klientových dotazů a příchozích odpovědí. Dá se říci, že odstaví útočníky z klientovy domácí sítě a případné další, kteří by dokázali odposlouchávat provoz po trase mezi klientem a jeho rekurzivním serverem. Díky šifrování jim zachycené pakety mnoho užitku nepřinesou. Od rekurzivního serveru dál už komunikace typicky probíhá otevřeně. Tady už se ovšem míchají dotazy všech klientů daného serveru a nemusí být snadné spojit si dotaz a tazatele.

Velkou otázkou je, kam šifrovaný tunel vede. Rekurzivní server na jeho konci uvidí vaše dotazy a bude předávat dál. Důvěřujete jeho provozovateli? Resolverem může být domácí krabička typu "vše v jednom", která zajišťuje rekurzivní řešení DNS dotazů pro místní počítače. V takovém případě nejspíš provozovateli budete věřit — jste to vy sami. Ale za resolverem se skrývá jen pár strojů z vaší domácnosti. Pokud někdo bude odposlouchávat jim předávané otevřené dotazy, dost se o vás dozví. Ochrana soukromí zde není veliká.

Opačným extrémem bude, když se šifrovaným spojem propojíte s veřejným otevřeným serverem. Na něj se obracejí miliony uživatelů a po dešifrování vaše dotazy jednoduše zmizí v davu. Ochrana proti útočníkům je tu velmi silná. Ale resolver samotný o vás ví vše. Provozovatelé některých veřejně deklarují, že nevedou záznamy o kladených dotazech, nic se neukládá na disky a soukromí uživatelů je dokonale chráněno. Případně si nechávají své chování ověřovat pravidelnými audity. Je už jen na vás, zda jim budete důvěřovat.

Ti nedůvěřiví mohou svou pozici posílit pomocí prostředníka (proxy). Soukromí uživatele ohrožuje propojení IP adresy tazatele a obsahu dotazu. Pomocí přostředníka lze tuto dvojici rozdělit: použijete šifrované DNS, ovšem nebudete dotazy posílat přímo serveru, ale prostředníkovi. Ten sice zná vaši adresu, ale nedokáže dešifrovat zprávy, takže neví, na co jste se ptali. Naproti tomu resolver dokáže dešifrovat obsah dotazu, ale nezná odesilatele — jemu dotaz dorazil z prostředníkovy IP adresy a na ni odpovídá. Aby toto uspořádání mělo smysl, musí samozřejmě stejný prostředník předávat dotazy od většího počtu klientů. Lze k tomu využít dnscrypt-proxy, podrobnější informace najdete na adrese:

https://github.com/DNSCrypt/dnscrypt-proxy/issues/960

Standardizovanou verzi tohoto přístupu představuje tak zvané zapomnětlivé DNS (Oblivious DNS) definované v RFC 9230 Oblivious DNS over HTTPS. Používá přenosový protokol HTTPS, prostředník a rekurzivní server se v němurčují pomocí URI šablony.

Jestli to stojí za námahu už musíte zvážit sami. Teď se podívejme, jaké máme pro šifrování DNS technické možnosti.

Jako první dovedla pracovní skupina dprive do podoby RFC použití populárního protokolu TLS, které je popsáno v RFC 7858 Specification for DNS over Transport Layer Security (TLS). Týká se komunikace mezi koncovým klientem a jeho rekurzivním serverem. V dalších fázích DNS komunikace by zřejmě byl použitelný též, nicméně ty leží už za hranicemi působnosti této specifikace.

Základní myšlenka je celkem jednoduchá — pro šifrované DNS je vyhrazen samostatný TCP port (konkrétně 853), na kterém server poslouchá, pokud službu podporuje. Klient, který má zájem o zachování soukromí, se nejprve zkusí připojit na port 853 a navázat TLS spojení. Pokud se nepodaří, může se vrátit ke standardnímu nešifrovanému DNS na portu 53. RFC 7858 výslovně zakazuje přenášet portem 853 nešifrované dotazy a odpovědi, je určen výlučně pro TLS. Na druhé straně pak zakazuje použití portu 53 pro TLS, tamní komunikace naopak musí být otevřená.

Zda se klient bude ochoten smířit s nešifrovanou komunikací, závisí na profilu použití TLS. RFC 7858 definuje dva základní:

Stručně řečeno, první profil dává přednost funkčnímu DNS i za cenu ztráty soukromí, zatímco přísný profil trvá na soukromí, i kdyby to znamenalo zůstat bez DNS. Podrobnější informace k oběma profilům poskytuje RFC 8310 Usage Profiles for DNS over TLS and DNS over DTLS.

Jakmile se podaří navázat TLS spojení, může klient klást dotazy. Nemusí se vždy čekat na odpověď, jakmile má další dotaz k řešení, může jej okamžitě odeslat. Server přicházející dotazy řeší a odpovědi posílá TLS spojením zpět. Nemusí dodržovat pořadí, jakmile má odpověď k dispozici, může ji odeslat. Klient si ji spáruje s dotazem podle Identifikátoru DNS zprávy. Pokud se řešení některého dotazu zdrží, mohou jej předběhnout odpovědi na pozdější dotazy.

Nevýhodou této varianty je, že na začátku zdržuje. Musí se navázat TCP spojení a následně TLS seance, což vyžaduje výměnu několika paketů. Ovšem týká se komunikace klientů s místním rekurzivním serverem. Klienti mívají k dispozici často jen jeden taková server ^[7] a jemyslitelné, že navázané spojení nechají otevřené a posílají po něm jeden dotaz za druhým. Počáteční režie se díky tomu rozpustí do řady dotazů a její dopad se minimalizuje. Kromě toho lze při opakovaném navazování nasadit různé urychlovače typu TCP Fast Open, obnovení TLS seance a podobně.

Je-li serverů přece jen více, klient by si z předchozí komunikace měl po omezenou dobu pamatovat, který podporoval DoT a který nikoli. Následně by měl zahajovat komunikaci rovnou tím protokolem, který použil minule. Případně může tuto informaci využít i k výběru serveru a dávat přednost těm, které umí šifrovat.

Pro přenosy po UDP vznikl podobný přístup, ovšem založený na protokolu DTLS. Jeho definici najdete v RFC 8094 DNS over Datagram Transport Layer Security (DTLS). Jedná se o experimentální RFC a sami jeho autoři předpokládají, že bude využívána spíš výše popsaná ochrana pomocí TLS. DoD je navrženo jako záložní varianta, v praxi se nepoužívá.

Teoreticky by mělo vyhovovat charakteru DNS lépe než DoT. DNS ke své činnosti používá především UDP, zatímco TCP je pro něj jen doplňkový mechanismus k přenosu dlouhých odpovědí. Kombinace UDP a šifrování je ovšem z principu kočkopes. UDP je bezstavové, přenáší samostatné datagramy, které mohou dorazit víceméně kdykoli. Naproti tomu šifrování potřebuje stavové informace — přinejmenším algoritmy a klíče, jimiž se zpráva šifrují a dešifrují. Používá se pro ně pojem kryptografický kontext a typicky se mezi partnery dohaduí na počátku komunikace. Nebezpečně to připomíná spojení, nicméně v DTLS se probíhající komunikaci říká seance (session).

Dorazí-li po UDP datagram, pro nějž příjemce nemá kryptografický kontext, typicky jej musí zahodit, protože jej nedokáže dešifrovat. Informuje o tom odesílatele a ten obvykle reaguje pokusem o vytvoření či obnovení kryptografického kontextu.^[8] Partneři používající DTLS proto musí být stále připraveni začít se šifrováním de facto znovu od začátku Kryptografie zkrátka velmi jednoduchý protkol UDP výrazně komplikuje a výsledné DTLS není v kolektivu příliš oblíbeno. Nicméně existuje a pro DNS se dá použít.

Základní principy jsou podobné předchozímu DoT: šifrovaná komunikace opět probíhá na (tentokrát UDP) portu 853, chování klienta je opět řízeno jeho bezpečnostním profilem. Počítá se s analogickými základními profily — příležitostným a přísným. RFC 8310 s definicí profilů je společné pro oba protkoly.

Odlišná je transportní vrstva a její šifrování. Hlavní výhodou DTLS je menší počáteční zdržení a rychlejší obnovení seance po přerušení. Stejně jako u TLS se počítá s tím, že odpovědi mohou přicházet v jiném pořadí než odchozí dotazy.

Významnou komplikací je, že specifikace DoD požaduje, aby se celá DNS zpráva včetně všech prvků DTLS vešla do jenoho datagramu. Jeho maximální velikost bývá 1500 B, což pro zprávy obsahující DNSSEC nemusí stačit. Navíc jestliže stroj nezná maximální velikost dtagramu na dané cestě (PMTU), musí podle RFC 8097 použít 1280 B.

Nevejde-li se odpověď, je server povinen ji zkrátit a opatřit příznakem zkrácení TC. Klient je tím nucen přejít ke spojové variantě — pokud možno DoT, případně i nešifrovanému TCP, pokud to jeho bezpečnostní profil připouští. Proto každá implementace DNS po DTLS musí podporovat i DNS po TLS. Zatím se implementace nijak nehrnou.

Zatím jedoznačně nejkontroverznější varianta ochrany DNS dotazů a odpovědí přišla s využitím protokolu HTTPS jako přenosového kanálu. U kolébky stála myšlenka, že současné sítě jsou protkány firewally a dalšími zařízeními, které omezují procházející pakety. DNS po TLS nebo DTLS může snadno narazit, pokud jeho vyhrazený port 853 nebude povolen. Naproti tomu web je de facto nutností a je dostupný všude. Jestliže se DNS zabalí do šifrovaného HTTP, uživatelé se k němu dostanou odkudkoli.

Druhou výhodou je, že nebude rozpoznatelné od běžné webové komunikace. Bude proto obtížné je filtrovat a případně se snažit přesměrovat na "jediné pravé servery", pokud by se někdo snažil s DNS manipulovat. Až dosud dobré. Problém spočívá v tom, že po vzniku definice DoH se přiřítili autoři webových prohlížečů a s elegancí slonů v porcelánu prohlásili, že umí HTTPS, takže po tomto mechanismu rádi sáhnou a budou si DNS řešit po svém, zcela mimo operační systém.

Tahounem je zejména Firefox, který v roce 2019 začal zavádět DoH s otevřeným serverem 1.1.1.1 jako výchozí mechanismus DNS. Začal v USE a postupně přidával další země. Při přechodu na tento způsob řešení DNS je uživatel upozorněn a může jej odmítnout. Kromě toho jej samozřejmě lze kdykoliv zapnout nebo vypnout v Nastavení. Ostatní prohlížeče jsou o něco umírněnější, nicméně DoH jejich aktuální verze už většinou umí. Na rozdíl od Firefoxu jej netlačí jako výchozí a vyžadují zapnutí, ale pokud by měly pocit, že Firefox díky němu získává body, rychle do toho vlaku naskočí.

Prvním problémem je, že DoH vedoucí na veřejný server jako výchozí mechanismus poskytuje jeho provozovateli hromadu soukromých dat. Společnost Cloudflare, která provozje server 1.1.1.1, veřejně deklaruje maximální ochranu uživatelských adt a nechává své postupy auditovat. Není důvod ji nevěřit, ale špetka nejistoty tam je. Navíc to silně podpoří centralizaci řešení DNS, valná většina uživatelů bude využívat několik málo veřejných otevřených serverů.

Druhá potíž spočívá v tom, že hrozí naprosté roztříštění obsahu DNS. Webový prohlížeč si bude řešit DNS po svém a ptát se jiných serverů než operační systém. Může proto dostávat jiné výsledky. Například pokud organizace používá neveřejné IP adresy a rozdělené DNS, kdy tazatelům z vnitřní sítě poskytuje jiné odpovědi, než dotazům zvenčí. Aplikace, která pomocí DoH využívá veřejný server, bude dostávat "venkovní odpovědi", zatímco systémový resolver bude poskytovat odpovědi určené pro místní tazatele.

Jestliže stejný přístup zvolí i další aplikace a vyberou si odlišné DNS servery, může vzniknout naprostá bramboračka. Pesimisté předpovídají vznik soukromých DNS stromů stavěných na míru konkrétním aplikacím, či službám. Řešit případné problémy s DNS v takovém případě bude za trest.

Z těchto důvodů je DoH považováno za velmi kontroverzní protokol. Žádnou výjimkou nejsou názory, že ochranu soukromí uživatelů ve skutečnosti zhorší. Jeden takový s rozsáhlou argumentací obsahuje například článek Hubert B.: Centralised DoH is bad for Privacy, in 2019 and beyond. Nicméně džin už je z láhve venku, musíme se s ním vypořádat. Podívejme se jak to pracuje.

Předskokanem byla stejnojmenná služba, kterou zavedl Google. S ní komunikuje protokol HTTPS, ovšem dotaz zakóduje do URL a odpověď přichází ve formátu JSON. Jedná se vlastně o webovou službu pro řešení DNS.

Výsledná specifikace DoH, kterou definuje RFC 8484 DNS Queries over HTTPS (DoH). je jiná. Ponechává formát DNS zpráv beze změny v původní binární podobě a HTTPS používá výlučně jako přepravní protokol. Využívá k tomu HTTP hlavičku:

Nesou ji dotazy i odpovědi. Resolver je identifikován sým URL, stejně jako běžná stránka. Například zmiňovaný otevřený resolver 1.1.1.1 je pro DoH k dispozici na adrese:

https://cloudflare-dns.com/dns-query

Pokud je na stejném stroji provozován i běžný web, nedá se poznat, zda klient řeší DNS nebo poptává běžnou stránku. Rozhodující pro rozlišení požadavků je cesta, která je ovšem zašifrována diky HTTPS. Charakter provozu by se dal rozpoznat jen podle vnějších příznaků, jako je velikost zpráv, jejich časování a podobně.

Každý DNS dotaz je reprezentován jedním HTTP požadavkem. Klient jej může položit metodami GET i POST. Použije-li GET, přidá za cestu jediný parametr dns=, jehož hodnotou bude DNS dotaz zakódovaný podle base64url. Při použití metody POST cesta neobsahuje žádné parametry a DNS dotaz se vkládá do těla HTTP požadavku. Je v binárním tvaru, tudíž kratší. Metoda GET je pro změnu vstřícnější k vyrovnávacím pamětem (HTTP cache). Server musí podporovat obě, volba je čistě na klientovi.

Odpověď se posílá jako standardní HTTP odpověď na příslušný požadavek. Na první pohled mohou být trochu matoucí stavové kódy — HTTP má svůj a DNS také. Ten v HTTP se týká výlučně HTTP transakce, DNS do něj nijak "neprosakuje". Jestliže řešení DNS skončí nějakým výsledkem, pošle se tazateli s HTTP kódem 2xx (úspěch), i kdyby DNS odpověď signalizovala chybu. HTTP se na situaci dívá tak, že posílá nějakou odpověď, tudíž transakce skončila úspěšně. Obsah odpovědi je pro ně irelevantní. Jen kdyby klient zadal chybnou cestu nebo nebyl oprávněn službu použít, odpovědel by server chybovým kódem na úrovni HTTP.

Součástí HTTP infrastruktury mohou být vyrovnávací paměti (HTTP cache). Ty samozřejmě nerozumí DNS, nicméně jejich obecný mechanismus poskytování uložených odpovědí na opakující se dotazy může využit i pro DoH. Vztahuje se jen na dotazy pokládané metodou GET, protože odpovědi POST se standardně neukládají. DNS dotaz obsahuje identifikátor trnasakce, který prakticky vylučuje opakování stejného dotazu. DoH proto požaduje, aby klient při jeho použití posílal nulový identifikátor. Párování DNS dotazů a odpovědí zajistí HTTP server.

Oříškem je doba životnosti odpovědí ve vyrovnávacích pamětech. Určuje ji odesílající server v HTTP hlavičce Cache-Control a nesmí být delší než životnost záznamů v DNS odpovědi. RFC 8484 doporučuje použít nejkratší životnost zdrojového záznamu z DNS odpovědi jako životnost HTTP odpovědi. Zasílá-li odpověď odpověď vyrovnávací paměť, přidá hlavičku Age obsahující její stáří — jak dlouho byla uložena. DoH klient musí její hodnotu odečíst od životnosti DNS záznamů v odpovědi. Jestliže je TTL záznamu 600 s a v HTTP bylo uvedeno stáří odpovědi 120 s, klient bude se záznamem pracovat, jako by měl TTL=480.

Specifikace dopporučuje používat HTTP verze alespoň 2, které umožňuje jedním spojením klást ze současně různé dotazy, aniž by se vzájemě blokovaly. Tato verze protokolu umožňuje serveru odesílat i data, která klient přímo nepožadoval, ale server předpokládá, že je bude potřebovat (server push). Tím lze rychlost odezvy ještě o něco zvýšit.

Navzdory výše zmiňovaným sporům, zda je DoH dobrý nápad, se protokol těší značnému zájmu ze strany vývojářů. O webových prohlížečích jsme se zmiňovali, v roce 2018 Microsoft oznámil, že se jej chystá zařadit do Windows. Od verze Windows 10 a Windows Server 2022 se skutečně dá DoH zapnout. Je třeba v konfiguraci síťového rozhraní vypnout automatické nastavení DNS serveru, zvolit jej ručně a přepnout na šifrovanou komunikaci. DoH se tak stalo prvním šifrovaným protokolem pro DNS v prostředí MS Windows.

QUIC je dost složitý transportní protokol vyvinutý firmou Google pro potřeby webu. Standardizován byl v RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport. Uvaříte jej podle násleujícího receptu:

Zprávy QUIC se přenášejí protokolem UDP, u kterého je vyzkoušeno, že v Internetu jen málokdy narazí. Společným zájmem webu a DNS je co nejméně zdržovat uživatele, proto QUIC obsahuje řadu postupů z TLS 1.3 pro minimalizaci počtu přenášených paketů a zrachlení některých operací. Patří sem například schopnost rychle obnovit dříve uzavřené spojení (klient se prokáže hodnotou z dřívějšího spojení) a okamžitě jim poslat dotaz (0-RTT). Také počet paketů, jimiž se na začátku nastavuje šifrování, je minimalizován, aby se mohlo co nejdříve začít přenášet něco užitečného.

Šifrovaným UDP kanálem se následně přenášejí nezávisle proudy (stream), původně určené pro dotazy prohlížeče a odpovědi serveru. Každý dotaz má svůj vlastní proud, který vznikne jednoduše tím, že se použije nové číslo proudu. V rámci jednotlivých proudů pak probíhají operace podobné TCP — potvrzují se pakety a chybějící se opakují. QUIC také zahrnuje řízení toku dat, aby se přenášelo co nejrychleji, ale zároveň nedošlo k zahlcení sítě nebo protějšího stroje. Proudy se vzájemně neovlivňují. Pokud v některém dojde ke zdržení, ostatní mohou nerušeně pokračovat.

Celkově se spojení protokolem QUIC chová velmi podobně jako svazek nezávislých TCP+TLS spojení,^[9] ovšem s podstatně menší režií. Společné šifrování a triviální zakládání proudů eliminují řadu výměn paketů a zrychlují komunikaci.

Popsané vlastnosti velmi vyhovují DNS. Počáteční inicializace spojení a nastavení parametrů šifrování, kvůli kterým jsou kritizovány protokoly TCP a TLS, je omezeno na minimum. Koncept nezávislých proudů je dobře využitelný pro jednotlivé dotazy. QUIC je zkrátka pro DNS dost vhodný protokol.

Teoreticky bychom pro jeho využití nic nepotřebovali. Definice DNS po HTTP už existuje a verze HTTP/3 přenáší své zprávy protokolem QUIC. Jenže balení DNS do HTTP znamená zbytečnou režii navíc. Proto vzniklo RFC 9250 DNS over Dedicated QUIC Connections, které zavádí jednodušší postup — přímočaré zasílání DNS zpráv protokolem QUIC.

Používá port 853, který byl přiřazen i DNS po DTLS. Tento konflikt v praxi příliš nevadí, protože se neočekává, že by se DoD významněji rozšířilo. Navíc QUIC dokáže sdílet společný port s jiným protokolem. Po dohodě obou stran lze použít i jiný port. Autoři zmiňují jako vhodný port 443, který používá HTTP/3 , takže bude všude povolen. Explicitně je zakázán port 53, aby nesváděl k nešifrované komunikaci.

Každý dotaz je kladen samostatným proudem. Má jej sám pro sebe, po zodpovězení se proud zavírá. Identifikátor v DNS zprávě musí být nulový, k párování dotazů a odpovědí slouží jen čísla proudů. Server na dotazy odpovídá v libovolném pořadí podle toho, jak má připraveny odpovědi. Například odpověď poskytnutá z vyrovnávací paměti může "předběhnout" odpověď na dřívější dotaz, kterou server teprve zjišťuje.

QUIC zahrnuje i zajímavý mechanismus jednoduchého ukončení spojení. Na začátku si obě strany dohodnou trpělivost — jak dlouho budou udržovat nečinné spojení. Jestliže po danou dobu není spojením přenesena žádná zpráva, automaticky se uzavře, aniž by si to komunikující strany dávaly nějak na vědomí. Díky jednoduchému obnovení spojení, kdy se pomocí 0-RTT dá položit rovnou další dotaz, to nic nestojí a dá se navázat, jako by spojení zůstalo aktivní. QUIC proto nemusí posílat žádné "udržovací" pakety, jejichž jediným cílem by bylo zachovat otevřené spojení.

DoQ vzniklo, stejně jako ostatní šifrovací varianty, zejména pro komunikaci koncových strojů s místními rekurzivními servery. Specifikace ale připouští i jeho použití mezi rekurzivním a autoritativním serverem nebo zónové přenosy. Malé režijní náklady QUIC činí takové využití myslitelným.

Zkusme se nejprve podívat na několik typických situací pro nasazení DNS, jejich základní charakteristiky, vyplývající požadavky na vlastnosti DNS infrastruktury a doporučené postupy, jak je naplnit.

Než začnete instalovat a konfigurovat servery, je velmi záhodno si nejprve srovnat noty a udělat si jasno, co všechno budete od DNS chtít a jaké cesty pro dosažení těchto cílů opvažujete za nejlepší. Za samozřejmost lze považovat poskytnutí sdílené vyrovnávací paměti (tedy rekurzivního serveru) pro místní klienty. K němu však může přibýt celá řada dalších úloh.

V první řadě si sepište seznam domén, pro které hodláte provozovat autoritativní servery. U každé z nich rozhodněte, kde bude primární a kde sekundární server(y), zatím pouze v obecné rovině, zda na vlastním serveru či externě. Nezapomeňte na reverzní zóny pro adresní rozsahy IPv4 a IPv6, kterými disponujete. Do hry mohou vstoupit i sekundární servery pro cizí zóny, které se třeba rozhodnete vést pro spřátelené instituce.

Druhou zajímavou otázkou je, zda máte na DNS speciální požadavky. Hodláte provozovat dynamické DNS? Chcete vybrané či všechny zóny zabezpečit pomocí DNSSEC? Provozujete software pro správu počítačů a/nebo konfigurací, na nejž má být DNS napojeno? Chcete do vnitřní sítě poskytovat jiné záznamy než veřejnosti (například s neveřejnými adresami)? Všechny tyto aspekty mohou mít dopad na volbu softwaru, který hodláte pro své servery použít.

V ideálním případě by tato fáze měla skončit dokumentem, v němž shrnete všechny požadavky: Jaké domény a s jakými vlastnostmi hodláte autoritativně spravovat.

Následně navrhněte jejich rozdělení na konkrétní servery. Na základě seznamu požadavků a topologie své sítě si rozmyslete, kde a kolik DNS serverů bude záhodno provozovat a jaké úkoly z předchozího seznamu kterému přidělit. Tím si uděláte jasno, kolik strojů budete potřebovat a jaké schopnosti musí nabídnout.

Posledním rozhodnutím pak bude výběr konkrétního programu, který nasadíte. Požadavky z předchozích bodů mohou zúžit váš výběr a vyřadit nekteré potenciální kandidáty. Pokud bude serverů více, použijete pro všechny stejný program, nebo budete řešení diverzifikovat? V prvním případě si usnadníte správu, ve druhém zvýšíte robustnost celého systému. Svou roli mohou samozřejmě hrát vaše zkušenosti či přístup ke zkušenostem s provozováním toho či onoho konkrétního programu.

Vřele doporučujeme výsledný návrh zdokumentovat a dokument pokud možno konzultovat. Zejména pokud jste museli v některých bodech netriviálně rozhodovat, je rozumné poznamenat si pro a proti jednotlivých variant a důvody přijatého rozhodnutí. Usnadníte si tak situaci, pokud se po pár měsících či letech praxe rozhodnete svůj návrh přehodnotit a samýšlet se nad jeho případnou úpravou.

Teprve když máte jasno v rozdělení úkolů, pusťte se do instalace a konfigurace jednotlivých programů. Určitě nic nezkazíte, pokud si budete v dokumentu odškrtávat, co máte hotovo. A pokud se později rozhodnete své uspořádání DNS změnit, nezapoměňte připravit novou verzi jeho dokumentace.

Úloha správce DNS je těžká a zodpovědná. (Předchozí větu zvýrazněte a doneste ukázat nadřízenému, až půjdete žádat o zvýšení platu.) Naštěstí existují různé programy a weby, kterými ji lze alespoň trochu usnadnit.

Než se do nich pustíme, zmiňme se o důležitém zdroji informací, kterými jsou záznamy (logy) o činnosti serverů. Oceníte je zejména při problémech a dohledávání jejich příčin. Doporučujeme ale sledovat je průběžně jako profylaxi. Najdete v nich časy důležitých událostí v životě serverů, jako jsou restarty, načtení zónového souboru, jeho přenost po síti, přijetí či odeslání upozornění na změnu v zóně. Za pozornost stojí i odmítnuté dotazy — pokud se jejich frekvence výrazně změní proti normálu, může to znamenat, že někdo zkouší na vaše severy útočit.

Za základní prostředek pro aktivní diagnostiku lze prohlásit obecné klienty, jimiž můžete zkoumat aktuální stav DNS a hledat příčiny problémů. Každý z nich umožňuje položit dotaz dotaz konkrétnímu serveru a ptát se na specifické záznamy, případně i s různými kombinacemi příznaků. V této souvislosti zmiňme RFC 8906 A Common Operational Problem in DNS Servers: Failure to Communicate, které rozebírá některé nešvary v chování DNS serverů. V kapitole 8 obsahuje sadu testů, jimiž zkontrolujete správnost chování svých serverů. Jsou zde uvedeny konkrétní příkazy s využitím programi dig, které zároveň poslouží jako ukázka jeho schopností a inspirace pro testování rafinovanějších dotazů.

Kromě obecných klientů existují i specializované nástroje. Mají na starosti diagnostiku a hledání chyb v datech či správu DNS dat, od níž si lze slibovat předcházení problémům. Ve zbývajících částech kapitoly se zkusíme podívat na vybrané kousky, které si podle nás zaslouží vaši pozornost. Lze je rozdělit do dvou základních kategorií, které z principuu mají odlišné přednosti a nedostatky:

Podívelme se na několik volně dostupných pomocníků.

Než se pustíme do konkrétních programů pro implementaci DNS serveru, podíváme se na několik obecných témat, společných pro všechny. Vyžadují rozhodnutí nebo aktivitu správce, ale neváží se ke konkrétnímu programu. Patří mezi ně například struktura zónových souborů nebo obecná koncepce poskytování DNS. Jim se budeme věnovat v této počáteční kapitole.

Rozumná struktura zónových souborů s daty a s nimi souvisejících konfiguračních souborů může podstatně usnadnit orientaci správce a tím veškeré jeho snažení. Za samozřejmost lze považovat umístnění zónových souborů do samostaqtného adresáře, například /etc/dns nebo v podadresáři /etc vyhrazeném pro konfiguraci DNS serveru. Zda v zónových souborech vytvářet další adresářovou hierarchii závisí především na tom, kolik jich bude a jaké zóny representují. Někdo se přiklání k odlišení primárních a sekundárních dat rozdělením do podadresářů primary a secondary. Jinou strategií by bylo zavést pro každou doménu další úrovně samostatný podadresář, zejména v situaci, kdy jich obhospodařujete větší počet.

Pro vlastní jména zónových souborů naopak existuje universální a jednoduché doporučení: nejvhodnější je přidělit jim jména totožná se jménem zóny, popřípadě s vhodnou příponou. Zónový soubor pro tul.cz tedy ponese jméno tul.cz a reverzní zóna pro 147.230.0.0/16 bude uložena v souboru 230.147.in-addr.arpa.

Kromě zónových souborů, pro něž má váš server poskytovat autoritativní odpovědi, mu však musíme dát do vínku jména localhost a seznámit jej s kořenovými servery.

Berkeley Internet Name Domain neboli BIND je široko daleko nejpoužívanější implmentací DNS serveru. Svého času poháněl drtivou většinu serverů a svět DNS byl téměř monokulturou. Internetová komunita cíleně podpořila vznik alternativních programů, protože dominance BINDu představovala riziko. Pokud by se objevila jeho závažná chyba, měla by zcela devastující dopad. V současné době již zastoupení BINDu kleslo podo 50%, ale stále pohání více serverů než kterýkoli z jeho konkurentů.

BIND může pracovat jako autoritativní i rekurzivní server a zvládá i obě role současně. Platí a dlouho ještě platit bude, že pokud vám stačí znát jeden program pro DNS server, s BINDem určitě neuděláte chybu. Jeho základní platformou jsou unixové systémy, k dispozici je zdrojový kód i balíčky pro různé distribuce. Program udržuje arozvíjí nezisková společnost ISC (Internet Systems Consorcium). BIND bývá součástí unixových a linuxových distribucí, kromě toho je volně ke stažení na webu:

https://www.isc.org/bind/

Masového rozšíření se dočkaly tři verze: BIND 4, 8 a 9, z nichž v současné době je udržována jen ta poslední. Neznamená to, že by třikrát došlo k výraznému rozšíření schopností programu. To se v případě BINdu odehrává při změně první číslice za desetinnou tečkou (v době vzniku tohoto textu je aktuální verzí 9.18). Autoři programu mění hlavní číslo verze pouze při zásadní změně vnitřní struktury programu. V roce 2009 byl zahájen vývoj BINu 10, který nedopadl dobře. Klíčovou verzí zůstává BIND 9, na nejž se soustředíme. Instalací programu nemá smysl se příliš zabývat. U systémů odvozených od Unixu bývá součástí distribuce. Pokud není implicitně nainstalován, stačí postupovat obvyklým způsobem, například doplnit balíček bind. Pokud byste z jakéhokoliv důvodu chtěli překládat ze zdrojového kódu, získáte jej na výše uvedené adrese.

Dlouhá léta býval přímo u ISC ke stažení i BIND pro MS Windows, ale jeho podpora skončila skončila s verzí 9.16. NAdále už binární distribuce pro MS Windows není podporována.

Součástí distribuce BINDu je několik podpůrných programů, které se jeho správci mohou hodit. Najdete mezi nimi všechny tři základní klientské programy (dig, host i nslookup) popsané v části Podpůrné programy, i sadu programů pro podepisování zón a další DNSSEC operace. Zde uvedeme jen programy, které bezprostředně souvisejí s vlastním provozem serveru.