DNS, domény, nameservery, TTL a DNSSEC

21. října 2016 přestaly fungovat Twitter, Spotify, Reddit, Netflix, PayPal, eBay i Amazon. Na hodiny, ve velkých částech USA i Evropy, přes padesát platforem najednou. A přitom všechny ty weby běžely. Servery jely, obsah byl na svém místě. Spadla jediná vrstva mezi nimi a uživatelem: DNS. Útok botnetu Mirai (tisíce IoT zařízení s továrními hesly, špička kolem 1 Tbps) zahltil firmu Dyn, která pro tyhle služby provozovala překlad jména na IP adresu. Nikdo nedokázal přeložit twitter.com na číslo, takže pro svět Twitter neexistoval.

To je celý smysl DNS v jedné nehodě. Je to telefonní seznam internetu. Když ho někdo vytrhne, je jedno, že volaný má zapnutý telefon. Nemáš číslo.

Rozdíl mezi doménou, DNS a hostingem stručně shrnuje slovník. Tahle kapitola ho rozvádí do detailu, který potřebuješ, abys při spuštění nerozbil web, e-mail ani ověřování služeb.

Tři vrstvy, tři dodavatelé, tři místa pro chybu

Doména, DNS a hosting jsou tři nezávislé služby. Můžeš je mít u tří různých firem a často je tak i máš, aniž bys to věděl.

Doména je pronajaté jméno. Platíš registrátorovi (Gandi, Namecheap, Forpsi) roční nájem za to, že firma.cz patří tobě. Nekupuješ ji, pronajímáš.

DNS je překlad toho jména na adresy. Drží ho authoritative nameserver — server, který pro tvou doménu odpovídá na otázku „jakou má IP". Když někdo zadá tvou adresu, jeho recursive resolver se prokouše kaskádou. Zeptá se root serveru, ten ho pošle na nameserver pro .cz, ten na tvůj authoritative nameserver, a ten teprve zná odpověď.

Hosting je místo, kde leží obsah. Origin nebo edge, na který DNS ukazuje. To řeší hosting a CDN.

Provozně na tom rozdělení záleží proto, že přepnutí nejčastěji rozbije e-mail, ne web. Při převodu domény mnozí registrátoři resetují nameservery na svoje výchozí a smažou existující DNS záznamy. Web přežije, protože ho nastavíš znovu jako první. Na MX záznam pro poštu se zapomene. Stalo se to: doména převedená na Shopify (registrátor OpenSRS, pošta na Google Workspace) měla e-mail nedoručitelný přes pět dní. MX záznam byl přitom „správně", jen u nesprávného nameserveru. Proto se vyplatí držet DNS u nezávislého poskytovatele odděleného od registrátora (Cloudflare, Route 53). Záznamy pak přežijí změny u registrátora. Daň je jedno místo navíc, kde se dá udělat chyba. Nic víc, žádné dogma.

Záznamy: co každý dělá

Záznam v DNS je řádek typu „tahle otázka → tahle odpověď". Typů je pár a stačí jim rozumět.

Typ	Co dělá
A	Mapuje jméno na IPv4 adresu (93.184.216.34).
AAAA	Totéž pro IPv6. Moderní resolver se ptá na oba, zařízení si vybere.
CNAME	Alias na jiné jméno. www.firma.cz → firma.cz.
MX	Poštovní server, který přijímá e-mail pro doménu. Nese prioritu — nižší číslo = vyšší přednost.
TXT	Libovolný text. Ověření vlastnictví domény a e-mailová autentizace (SPF, DKIM, DMARC).
NS	Authoritative nameservery zóny.
SOA	Administrativní parametry zóny (jen jeden, povinný).
CAA	Které certifikační autority smí vydat TLS certifikát pro doménu.

CAA stojí za zmínku. Od roku 2019 (RFC 8659) CA před vydáním certifikátu kontroluje CAA záznam a odmítne vystavit, pokud tam není uvedená. Je to pojistka proti tomu, aby cizí CA vydala certifikát na tvou doménu. Samotné vydávání a obnovu certifikátů (Let's Encrypt, ACME, 90 dní) řeší hosting a CDN. DNS se TLS dotýká jen přes tenhle jeden záznam.

CNAME na apex nepatří

Na tohle narazí každý jednou. CNAME nejde dát na apex domény, tedy na holé firma.cz bez prefixu.

Důvod je v RFC 1034 z roku 1987: „Je-li v uzlu záznam CNAME, nesmí tam být žádná jiná data." Jenže apex má povinné NS a SOA záznamy a typicky i MX. CNAME by je vytlačil. Takže firma.cz jako CNAME standardně nelze, zatímco www.firma.cz ano. Apex a www se proto nastavují každý jinak.

Řešení jsou dvě, obě mimo standard. ALIAS (nebo ANAME) je záznam, kde poskytovatel cíl interně vyhodnotí a vrátí rovnou A/AAAA. CNAME flattening dělá totéž jinak: Cloudflare ti dovolí napsat CNAME na apex a sám ho při dotazu zploští na A/AAAA. Funguje to, ale nepřenese se. Jiný poskytovatel ALIAS mít nemusí. Konkrétní nastavení flatteningu a proxy statusu řeší Cloudflare v praxi.

TTL je hodiny dopředu, ne tlačítko

TTL (time to live) je počet sekund, po které smí resolver držet záznam v cache, než si řekne o čerstvý. Z toho plyne věc, kterou skoro každý pochopí špatně až po prvním zkaženém přepnutí.

Změna záznamu se neprojeví všude naráz. Staré kopie žijí v cachích resolverů po celém světě, dokud jim nevyprší TTL. Pokud má A záznam TTL 86400 (den), může někdo dostávat starou IP ještě celý den po změně.

A teď část proti intuici. Snížit TTL a hned měnit záznam nic neudělá. Resolvery už drží starou hodnotu se starým, vysokým TTL. Nové nižší TTL respektují až poté, co jim ta existující cache vyprší. Snížení tedy musí proběhnout aspoň jeden plný starý TTL předem. Vynechání tohohle kroku je nejčastější příčina nečekaně dlouhé propagace.

Postup migrace proto vypadá takhle:

1. 24–48 hodin předem sniž TTL na 300 sekund (5 minut).
2. Počkej aspoň jeden plný starý TTL, ať se nová nízká hodnota rozšíří.
3. Teprve teď přepni záznam. Propagace doběhne za minuty, ne za den.
4. Po přepnutí TTL zase zvedni zpátky (běžný „klidový" A záznam 3600–86400 s).

Z téhle teorie se ve chvíli migrace stává plán. Operační kroky jsou ve spuštění a migraci.

DNS není jen web. Je to e-mail a důvěra.

Na A a CNAME při spuštění nikdo nezapomene — web by nešel a hned se to pozná. Zapomínají se „ne-webové" záznamy, protože jejich výpadek není vidět okamžitě. Pošta odchází, jen ji adresát hází do spamu. Trojice TXT záznamů řeší, aby tvůj e-mail někdo bral vážně:

• SPF vyjmenuje IP adresy, které smí odesílat poštu za tvou doménu. Přijímající server porovná odesílatele se seznamem.
• DKIM je kryptografický podpis odchozí pošty. Příjemce ho ověří veřejným klíčem z tvého DNS. Zaručuje, že zpráva nebyla cestou změněná a vážně přišla od tebe.
• DMARC staví nad oba. Říká příjemci, co dělat se zprávou, která neprošla SPF ani DKIM: odmítnout (reject), dát do karantény (quarantine), nebo jen monitorovat. A posílá ti reporty.

Bez nich pošta technicky odejde. Jen skončí ve spamu nebo ji adresát vůbec nedostane. A ty se to dozvíš, až si někdo postěžuje.

DNSSEC: podpis, ne šifrování

Obyčejné DNS odpovědi se dají podvrhnout. Útočník mezi tebou a resolverem ti pošle falešnou IP a ty skončíš na jeho serveru, aniž bys poznal rozdíl. DNSSEC to řeší tím, že odpovědi kryptograficky podepisuje. Resolver pozná, jestli data někdo cestou nezměnil. Nešifruje. Obsah zůstává veřejný, jen je ověřitelný.

Mechanika stojí na řetězu důvěry. Zóna publikuje klíče v záznamu DNSKEY: ZSK (zone signing key) podepisuje data zóny, KSK (key signing key) podepisuje sadu DNSKEY. Hash toho KSK se uloží jako záznam DS do rodičovské zóny, tedy u TLD. Když resolver ověřuje, vezme KSK z tvé zóny, spočítá jeho hash a porovná ho s DS, který má od rodiče. Tak vznikne globální řetěz: root ručí za .cz, .cz za tvou doménu.

Není to ale automatická volba. Špatně provedená výměna klíčů nebo expirovaný podpis udělají doménu nedostupnou pro každý validující resolver. To je tvrdší výpadek než vůbec žádný DNSSEC. Ber ho jako vědomé rozhodnutí, ne reflexivní zaškrtnutí.

Přesto je to v Česku běžné. Na konci roku 2024 spravoval CZ.NIC 1 485 493 domén .cz, z toho 883 698 (59,5 %) zabezpečených DNSSEC. Přes hranici 50 % se .cz dostalo už v roce 2016 a patřilo mezi světové průkopníky.

Tři typické záměny

• „Doména, DNS a hosting je jedno." Tři nezávislé služby u klidně tří dodavatelů. Přepnutí rozbíjí e-mail, ne web, protože MX se zapomene.
• „TTL stačí snížit těsně před přepnutím." Ne. Resolvery drží starou hodnotu se starým TTL. Snížit se musí aspoň jeden plný starý TTL předem.
• „CNAME můžu dát kamkoli." Ne na apex (RFC 1034). ALIAS nebo flattening to obchází, ale není to standard a nepřenese se mezi poskytovateli.

Praktický checklist

• Před změnou je inventura všech záznamů, včetně MX, SPF, DKIM, DMARC a CAA.
• TTL je snížené aspoň jeden starý TTL před přepnutím, ne až těsně.
• Existuje vlastník domény, DNS a e-mailových záznamů — víš, kdo má přístup ke každé vrstvě.
• DNS je u poskytovatele odděleného od registrátora, nebo je riziko ztráty záznamů při převodu jinak ošetřené.
• DNSSEC je vědomé rozhodnutí včetně plánu na výměnu klíčů.

Zdroje

• Cloudflare Learning, RFC 8659 — authoritative nameserver, recursive resolver, CAA.
• CleanBrowsing, dnscale, ClouDNS — typy záznamů A/AAAA/CNAME/MX/TXT, priorita MX.
• RFC 1034 (1987), dchost, NameSilo — CNAME na apexu nelze, ALIAS/ANAME, CNAME flattening.
• dchost — TTL best practices, nutnost snížit TTL jeden starý TTL předem, okno 300 s.
• Valimail, Mailforge, Microsoft Learn — SPF/DKIM/DMARC jako TXT záznamy.
• Samuraj, Codilime, DNSimple — DNSSEC, DNSKEY (ZSK/KSK), DS, chain of trust.
• Wikipedia, KrebsOnSecurity — Dyn DDoS 21. 10. 2016, Mirai, ~1 Tbps, padlé platformy.
• CZ.NIC / Internet Society — .cz DNSSEC: 883 698 z 1 485 493 domén (59,5 %), průlom 50 % v 2016.
• Shopify community, dn.org — ztráta MX při transferu (OpenSRS / Google Workspace, 5+ dní).

DNS sedí mezi doménou ze slovníku a hostingem a CDN, na který A/AAAA/CNAME ukazují. Konkrétní nástroj té vrstvy (proxy status, flattening, TLS módy) je Cloudflare. Přepnutí, snížení TTL a zapomenuté ne-webové záznamy patří do spuštění a migrace.