Web může mít výkonný server, rychlou databázi i dokonale zkomprimované obrázky, a přesto se návštěvník několik vteřin dívá na prázdnou stránku. Někdy za to může DNS – nenápadná vrstva internetu, která rozhoduje, kam se prohlížeč vydá.
Představme si běžný večer. Správce e-shopu nasadí novou verzi, zákazník zadá adresu obchodu a stiskne Enter. Prohlížeč zatím neví, kde web skutečně bydlí. Z názvu domény musí zjistit IP adresu serveru. Teprve potom může navázat spojení, stáhnout stránku a začít vykreslovat obsah. Když se DNS dotaz zdrží nebo dorazí k nesprávnému cíli, zpoždění vznikne ještě před načtením prvního pixelu webu.
DNS jako telefonní seznam internetu
DNS, tedy systém doménových jmen, převádí snadno zapamatovatelný název na číselnou adresu serveru. Člověk si zapamatuje například doménu, počítač pracuje s IP adresou. Resolver, který DNS dotaz vyřizuje, nejprve zkontroluje vlastní cache. Pokud v ní odpověď najde a její platnost ještě nevypršela, může ji vrátit okamžitě.
Když záznam v cache není, začíná pátrání. Resolver se může postupně obrátit na kořenový server, server pro příslušnou doménu nejvyšší úrovně, například .cz nebo .com, a nakonec na autoritativní nameserver, který zná konkrétní nastavení domény. U nezacyklovaného dotazu může taková cesta vyžadovat až osm kroků. Každý z nich přidává malé zpoždění, a pokud některý server odpovídá pomalu nebo vůbec, návštěvník to pocítí jako pomalé načítání webu.
Kořenový systém přitom není jediný počítač někde v jedné serverovně. Funguje jako distribuovaná síť: existuje 13 kořenových identit spravovaných 12 operátory a více než 1 500 instancí rozmístěných po světě. Díky anycastu se DNS dotaz obvykle dostane k nejbližší dostupné instanci. Stejný princip používají i další rozsáhlé DNS služby. Vzdálenost mezi návštěvníkem a odpovídajícím serverem tak může být kratší, než by napovídala samotná doména.
Cache, TTL a rychlost změn
Největší práci za DNS často udělá cache. Resolver si odpověď uloží a při dalším dotazu nemusí celou cestu opakovat. Délka tohoto uložení se řídí hodnotou TTL, tedy dobou, po kterou je záznam považován za platný.
Delší TTL obvykle znamená vyšší šanci, že návštěvník dostane odpověď z cache. To urychluje načtení a snižuje počet dotazů, které musí DNS infrastruktura obsloužit. U proxy záznamů používá Cloudflare TTL 300 sekund. U neproxovaných záznamů lze nastavit hodnoty od 60 sekund do jednoho dne.
Jenže DNS je plné kompromisů, které se projeví až ve chvíli, kdy je potřeba něco změnit. Při dlouhém TTL mohou resolvery ještě hodiny používat starou IP adresu. Přesměrování na nový server se proto neprojeví u všech návštěvníků okamžitě. Krátké TTL změnu urychlí, například při přesunu webu nebo přesměrování provozu po výpadku, zároveň ale zvýší počet DNS dotazů a závislost na dostupnosti resolverů.
CNAME umí přidat další zastávku
DNS záznamy nemají všechny stejnou úlohu. Záznam A ukazuje přímo na IPv4 adresu, AAAA na IPv6 adresu. CNAME místo toho říká, že jeden název je aliasem jiného názvu. To se hodí u služeb provozovaných třetí stranou, CDN nebo cloudových platforem.
Alias ale může znamenat další lookup. Resolver nejprve zjistí, kam CNAME odkazuje, a potom musí dohledat adresu cílového názvu. Jeden takový krok navíc nemusí být problém. Řetězec několika CNAME záznamů už může prodloužit odpověď a zkomplikovat hledání chyby. Když některý článek řetězce zmizí, ukazuje na neexistující název nebo se dostane do smyčky, web může být pomalý či úplně nedostupný.
Tohle je přesně ten druh potíže, který správce často přehlédne. V prohlížeči vidí chybovou stránku, zatímco server samotný běží bez jediné chyby. DNS se totiž pokazilo ještě předtím, než se k němu požadavek vůbec dostal.
Dostupnost nestojí jen na jednom serveru
Správné nastavení DNS neznamená pouze zadat jednu IP adresu a dál na ni zapomenout. U důležitých webů se používá více serverů, geograficky rozdělená infrastruktura nebo DNS služba s anycastem. Dotaz pak může obsloužit nejbližší dostupná instance. Když jedna část sítě selže, provoz se může přesunout jinam, aniž by návštěvník musel měnit adresu v prohlížeči.
Samotný počet nameserverů však nezachrání špatnou konfiguraci. Nameservery musí být dostupné, jejich odpovědi se musí shodovat a doména musí mít správně nastavenou delegaci. Chyba v jediném záznamu může způsobit, že část resolverů dostane jinou odpověď než část ostatních. Výsledkem bývá nepravidelný výpadek: web funguje z jedné sítě, ale z jiné se neotevře.
Při diagnostice se proto vyplatí sledovat nejen server a aplikaci, ale také autoritativní odpovědi, TTL, řetězce aliasů a chování z různých míst. Osobně považuji DNS za internetovou obdobu navigace: když ukazuje špatně, ani nejrychlejší auto vás nedoveze k cíli.
DNSSEC chrání odpověď, ale chyba může web odříznout
DNSSEC přidává k DNS odpovědím kryptografické podpisy. Resolver si díky nim může ověřit, že záznam nebyl po cestě podvržen nebo změněn. Bezpečnostní vrstva ovšem vyžaduje přesně sladěné záznamy. Když podpis nesedí, vyprší nebo neodpovídá aktuálnímu klíči, validující resolver může odpověď odmítnout.
Pro návštěvníka pak doména působí, jako by neexistovala, přestože webový server běží a jeho IP adresa je správná. Podle sledování ICANN provádělo v srpnu 2026 validaci DNSSEC 39,57 procenta sledovaných resolverů. Chyba proto nemusí zasáhnout všechny uživatele stejně, což z ní dělá mimořádně nepříjemný problém při hledání příčiny.
Správce domény by měl před změnou nameserverů, klíčů nebo podpisů ověřit, že na sebe jednotlivé části navazují. Změny je rozumné plánovat s ohledem na TTL a počítat s tím, že staré odpovědi mohou v některých cache ještě určitou dobu zůstávat. DNS sice pracuje tiše na pozadí, ale každá jeho chyba se nakonec projeví velmi viditelně: pomalým načtením, přesměrováním na nesprávný server nebo prázdnou stránkou místo objednávky.
