DNS, domény a nameservery

V říjnu 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ě, aplikace byly připravené odpovídat.

Selhala vrstva mezi názvem domény a serverem: DNS. Útok botnetu Mirai - přibližně sto tisíc kompromitovaných IoT zařízení se špičkou kolem 1 Tbps - zahltil firmu Dyn, která pro tyhle služby provozovala DNS, tedy překlad jména na IP adresu. Když si prohlížeč nedokázal přeložit twitter.com na číslo, Twitter pro něj prakticky neexistoval.

DNS rozhoduje, kam půjde web, pošta, certifikát i ověření cizích služeb. Když se rozbije, často to nejdřív nevypadá jako problém DNS. Jen přestane chodit e-mail, ověření domény selže, nebo část lidí pořád vidí starý web.

Tři vrstvy

Doména, DNS a hosting nejsou jedna služba. Můžeš je mít u tří různých firem a často je tak máš a u velkých projektů je to i doporučovaný způsob.

Doména je pronajaté jméno. Platíš registrátorovi (Gandi, Namecheap, Forpsi) roční poplatek za to, že firma.cz patří tobě. Nekupuješ ji navždy, držíš k ní právo po zaplacenou dobu. A můžeš si zřizovat nekonečno subdomén (tedy www.firma.cz, moje.www.firma.cz, apod), platíš pouze za to firma.cz tomu, kdo provozuje doménu .cz. V ČR je to uskupení CZ.NIC, v každé zemi je to někdo jiný a má jiná pravidla. Některé národní domény nelze koupit, pokud nejste občas dané země.

DNS říká, kam to jméno vede. Odpovídá za něj authoritative nameserver, tedy server, který pro tvou doménu zná správné záznamy. Když někdo zadá adresu, jeho recursive resolver se postupně doptá root serveru, nameserveru pro .cz a nakonec tvého authoritative nameserveru. A dostane zpátky nějaké číslo, buď tzv. IPv4 (10.1.1.1 apod) nebo moderní IPv6 (2001:0db8:85a3:08d3:1319:8a2e:0370:7344), protože IPv4 adresy už došly, hups.

Hosting je místo, kde leží obsah nebo běží aplikace. Může to být origin, edge, statický hosting nebo serverový runtime. Tomu se věnuje kapitola hosting a CDN.

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

DNS záznam je řádek typu „na tuhle otázku vrať tuhle odpověď". Základních typů není mnoho.

CAA je malý záznam s velkým dopadem, kterej nás občas "vytrestá". Certifikační autorita má před vydáním certifikátu zkontrolovat, jestli jí to CAA záznam dovoluje. Když CAA existuje a danou autoritu nepovoluje, certifikát nevydá. Není to náhrada za správu TLS, ale pojistka proti tomu, aby certifikát pro tvou doménu vydala autorita, kterou nechceš používat. No a klient ho má občas nastavený a třeba Cloudflare v něm nemusí být.

CNAME na apex nejde dát

CNAME nejde standardně dát na apex domény, tedy na holé firma.cz bez prefixu.

Důvod je starý, ale už ho nikdo nikdy nezmění. RFC 1034 říká, že když má uzel CNAME, nesmí mít žádná další data. Jenže apex domény musí mít NS a SOA záznamy a často na něm bývá i MX. CNAME by je vytlačil. www.firma.cz jako CNAME projde, firma.cz jako CNAME standardně ne. A proto potřebujeme i IP adresu a nevystačíme si s CNAME, protože web na apexu běžet musí. Ale i proto preferujeme spouštět web na subdoméně (www.firma.cz) a apex jenom přesměrovávat na ní.

TTL a příprava na přepnutí

TTL (time to live) je počet sekund, po které smí resolver držet záznam v cache. Dokud TTL nevyprší, resolver se na autoritativní nameserver znovu neptá. Je to prostě taková kaskáda.

To je důvod, proč se změna DNS neprojeví všude najednou. Staré odpovědi žijí v cachích resolverů po celém světě. Když má A záznam TTL 86400 sekund, někdo může dostávat starou IP ještě skoro celý den po změně.

No a když si toho všimneme hodinu před spuštěním, máme problém. Snížit TTL už těsně před změnou nepomůže. Resolvery už drží starou odpověď se starým, vysokým TTL. Novou nízkou hodnotu uvidí až po vypršení staré cache. Pokud se vám to stane, reálně je potřeba spustit nový web až další den.

Proto snížení TTL proto musí proběhnout aspoň jeden plný starý TTL před přepnutím. Pokud dnes držíš záznam s TTL jeden den, sniž ho nejméně den předem.

Praktický postup migrace:

1. 24-48 hodin předem sniž TTL na 300 sekund. (Často je výchozí hodnota 3600 a to se vyplatí snížit.)
2. Počkej aspoň jeden plný starý TTL, aby resolvery převzaly novou nízkou hodnotu.
3. Teprve potom přepni záznam. Propagace se bude počítat spíš v minutách než v hodinách.
4. Po stabilizaci TTL zase zvedni, typicky na 3600-86400 sekund podle povahy záznamu.

DNS neovládá jen web

Když se v DNS rozbije web, tak nejde otevřít a chyba je vidět hned.

Horší jsou záznamy, které nevypadají jako web. MX rozhoduje, kam chodí pošta. TXT záznamy dokazují, že smíš používat doménu v cizích službách. A SPF, DKIM a DMARC rozhodují, jestli budou příjemci tvou poštu brát vážně.

• SPF vyjmenuje servery, které smí odesílat poštu za tvou doménu. Přijímající server porovná skutečného odesílatele se seznamem.
• DKIM podepisuje odchozí poštu kryptografickým podpisem. Příjemce ověří podpis veřejným klíčem z DNS a pozná, jestli se zpráva cestou nezměnila.
• DMARC staví nad SPF a DKIM. Říká příjemci, co dělat se zprávou, která pravidly neprošla: odmítnout (reject), dát do karantény (quarantine), nebo jen monitorovat. Umí také posílat reporty.

Bez těchto záznamů se pošta může technicky odeslat. Jen ji příjemce častěji zahodí, přesune do spamu, nebo odmítne bez zjevného vysvětlení pro uživatele. A ty to často zjistíš až z odpovědi „nic mi nepřišlo".

DNSSEC podpis

Obyčejná DNS odpověď se dá podvrhnout. Útočník mezi tebou a resolverem může poslat falešnou IP adresu a uživatel skončí na jiném serveru, aniž by mu samotné DNS řeklo, že se něco změnilo.

DNSSEC odpovědi kryptograficky podepisuje. Resolver pak pozná, jestli data cestou někdo neupravil. Nešifruje je. DNS odpovědi zůstávají veřejné, jen k nim přibude ověřitelný podpis.

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 KSK se uloží jako záznam DS do rodičovské zóny, tedy u TLD. Resolver pak porovná klíč z tvé zóny s DS záznamem od rodiče. Root ručí za .cz, .cz ručí za tvou doménu.

DNSSEC je super, ale špatná výměna klíčů nebo expirovaný podpis může doménu zneviditelnit pro validující resolvery. To je pak průšvih, který může trvat dny napravit.

V Česku je DNSSEC zároveň běžný. Ke konci roku 2024 uváděl 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 první velké TLD, kde se DNSSEC opravdu rozšířil. Mimochodem obecně česká doména je technicky jedna z nejlepších na světě a organizace CZ.NIC je globálně velmi respektovaná.

OMG musím tomu rozumět?

Jo. Aspoň do míry, že víš, čemu nerozumíš a tím pádem na to nesaháš.

Potřebuješ vědět, kdo drží doménu, kde běží autoritativní DNS, kam vedou webové záznamy a co se stane s poštou při změně. Jinak hrozí, že něco hodně pokazíš.

Tři typické záměny

• „Doména, DNS a hosting je jedno." Nejsou. Jsou to tři vrstvy, které mohou mít tři různé dodavatele. Při změně domény se proto snadno ztratí pošta, i když web znovu nastavíš.
• „TTL stačí snížit těsně před přepnutím." Nestačí. Resolvery už drží starou odpověď se starým TTL. Snižuj aspoň jeden plný starý TTL předem.
• „CNAME můžu dát kamkoli." Ne na apex podle standardního DNS. ALIAS, ANAME nebo flattening to umí obejít, ale nejsou přenositelné mezi poskytovateli.

Praktický checklist

• Před změnou existuje inventura všech záznamů, včetně MX, SPF, DKIM, DMARC, ověřovacích TXT/CNAME a CAA.
• TTL je snížené aspoň jeden starý TTL před přepnutím, ne až těsně před změnou.
• Víš, kdo vlastní přístup k registrátorovi, DNS poskytovateli a e-mailové službě.
• DNS je buď oddělené od registrátora, nebo je jinak ošetřené riziko, že transfer domény přepne nameservery a ztratí záznamy.
• Apex a www jsou nastavené vědomě; CNAME na apexu spoléhá jen na podporovanou funkci poskytovatele.
• DNSSEC je zapnutý jen tehdy, když existuje plán na správu klíčů a kontrolu podpisů.