DNSSEC pro majitele domén: před čím chrání a jak ho zapnout

DNSSEC přidává k DNS záznamům vaší domény kryptografické podpisy, takže validující resolver podvrženou odpověď odmítne, místo aby návštěvníka poslal na cizí server. Zapnutí vyžaduje dva kroky na dvou místech: váš poskytovatel DNS podepíše zónu a registrátor zveřejní záznam DS v nadřazené zóně (.com, .net, národní doména). Pokud k sobě obě poloviny přestanou pasovat (starý DS po výměně klíče nebo po přechodu k jinému poskytovateli DNS, vypršené podpisy), validující resolvery vracejí SERVFAIL a web zmizí přibližně 40 % uživatelů internetu, zatímco ostatní ho dál vidí.

Před čím DNSSEC chrání a před čím ne

DNSSEC odpovídá na jedinou otázku: přišla tato odpověď DNS opravdu od vlastníka zóny a beze změny? Vše, co umí a neumí, z toho vyplývá.

Řetězec důvěry: dvě poloviny na dvou místech

Váš poskytovatel DNS drží klíče zóny, obvykle dva: KSK (key signing key) podepisuje sadu klíčů, ZSK (zone signing key) všechno ostatní. Veřejné části jsou v zóně jako záznamy DNSKEY a každá sada záznamů nese podpis RRSIG. Podepsaná zóna sama o sobě nic nedokazuje, protože zónu může podepsat kdokoli vlastním klíčem. Proto registrátor předá registru záznam DS, tedy otisk (hash) vašeho KSK. Zóna .com je podepsaná klíčem registru, za který zase ručí kořenová zóna. Resolveru stačí kořenový klíč a sestupuje po řetězci článek po článku.

Ověřený řetězec v našem testovacím prostředí (výstup drill -S):

www.good.lab. (A)
|---good.lab. (DNSKEY keytag: 64049 alg: 13 flags: 256)
    |---good.lab. (DNSKEY keytag: 63839 alg: 13 flags: 257)
    |---good.lab. (DS keytag: 63839 digest type: 2)
        |---lab. (DNSKEY keytag: 42416 alg: 13 flags: 256)
            |---lab. (DNSKEY keytag: 50413 alg: 13 flags: 257)
            |---lab. (DS keytag: 50413 digest type: 2)
                |---. (DNSKEY keytag: 16174 alg: 13 flags: 256)
                    |---. (DNSKEY keytag: 65449 alg: 13 flags: 257)
;; Chase successful

Pro majitele webu je klíčovým signálem příznak ad (authenticated data) v odpovědi validujícího resolveru:

$ dig @127.0.0.1 www.good.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22876
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.good.lab.   300 IN A     192.0.2.10
www.good.lab.   300 IN RRSIG A 13 3 300 20261124104054 20261110141320 64049 good.lab. 3q/P...

Ve skutečném internetu použijte dig +dnssec example.com @1.1.1.1 nebo delv example.com: delv řetězec sám ověří a vypíše ; fully validated. DNSViz vykreslí každý článek řetězce.

Jak zapnout DNSSEC pro svou doménu

1. Zjistěte, kdo je váš poskytovatel DNS a kdo registrátor. dig NS example.com +short ukáže servery, které za zónu odpovídají. Pokud jsou DNS i registrace u stejného poskytovatele, bývá DNSSEC jeden přepínač a DS se předá automaticky.
2. Zapněte podepisování u poskytovatele DNS. Server vytvoří klíče a podepíše zónu. Musí ji také sám znovu podepisovat: v našem prostředí nastavoval BIND s dnssec-policy podpisy s platností asi 14 dní a sám je obnovoval. Ruční podepisování bez automatizace končí vypršenými podpisy.
3. Získejte záznam DS. Má čtyři pole: key tag, algoritmus, typ otisku a otisk. Příklad z testu: good.lab. 3600 IN DS 63839 13 2 0E1736F2... (algoritmus 13 = ECDSA P-256, typ 2 = SHA-256). Někteří registrátoři chtějí místo toho DNSKEY s příznakem 257.
4. Zadejte DS u registrátora. Registrátor ho předá registru a objeví se v zóně .com (nebo jiné TLD). Některé registry umí převzít DS automaticky ze záznamů CDS/CDNSKEY (RFC 8078), ale předem s tím nepočítejte.
5. Ověřte výsledek. dig DS example.com +short by měl ukázat váš DS a dig example.com +dnssec @1.1.1.1 příznak ad. Pokud místo toho dostanete SERVFAIL, DS u registrátora hned odstraňte a hledejte nesoulad.

Pokud je vaše doména registrovaná u RichHost, zeptejte se podpory, zda pro ni lze DNSSEC zapnout a jak předat záznam DS: podpora pracuje 10:00-20:00 kyjevského času a odpovídá zhruba do 30 minut. Samotný hosting najdete v tarifech hostingu RichHost.

Jak přerušený řetězec schová web: tři poruchy v testu

Ve všech třech případech autoritativní server běžel a vracel správnou IP adresu. Selhala jen validace, takže logy hostingu nic neobvyklého neukazují, zatímco návštěvníci za validujícím resolverem dostávají SERVFAIL. Pro ně web prostě nejde najít, podobně jako u jiných chyb DNS v prohlížeči. Unbound příčinu vysvětlí kódem EDE (Extended DNS Error), což je při hledání chyby nejužitečnější vodítko.

1. Nový klíč, starý DS

Vyměnili jsme KSK zóny roll.lab a zónu znovu podepsali, ale v „registru“ nechali starý DS. Stává se to, když se klíče mění ručně nebo když zóna přechází na jiné servery s novými klíči.

15:14:53 KSK 8235 replaced by 51389, parent DS still 8235
15:14:54 resolver 2 (cold): SERVFAIL  EDE 6 (DNSSEC Bogus): no keys have a DS with algorithm ECDSAP256SHA256
15:14:54 resolver 1 (warm): NOERROR ad 192.0.2.10
15:18:59 resolver 1 (warm): NOERROR ad, TTL 12
15:19:29 resolver 1 (warm): SERVFAIL  EDE 6 (DNSSEC Bogus)
15:23:00 correct DS (51389) published in the "registry"
15:27:30 both resolvers: SERVFAIL (old DS cached with TTL 3600)
15:27:48 resolver 2 after unbound-control flush_zone roll.lab: NOERROR ad
16:15:09 resolver 1, no intervention: NOERROR ad

Zrádné je, že resolver, který už klíče zóny znal, odpovídal normálně ještě 4,5 minuty (TTL 300). Majitel web zkontroluje, vidí, že funguje, a noví návštěvníci už přitom dostávají chybu. Ani oprava nezabere hned: správný DS jsme zveřejnili v 15:23, ale resolver držel starý DS po celou dobu jeho TTL (3600 sekund) a k normálním odpovědím se vrátil až v 16:15, o 52 minut později. Celkem byl web přes tento resolver nedostupný 56 minut. V .com je TTL záznamu DS 24 hodin, takže ve skutečném internetu může tato chyba stát celý den. Google Public DNS uvádí, že ukládání do cache obvykle omezuje na 6 hodin, a Google i Cloudflare umožňují doménu ze své cache ručně vymazat.

2. Vypršené podpisy

Zónu expold.lab jsme podepsali podpisy, které vypršely už o 2 hodiny dříve. Resolver to hlásí jasně:

$ dig @127.0.0.1 www.expold.lab A +dnssec
;; status: SERVFAIL
; EDE: 7 (Signature Expired): (validation failure <www.expold.lab. A IN>: signature expired from 127.0.22.10 for key expold.lab. while building chain of trust)

Zajímavé je, co se děje přesně v okamžiku vypršení. Zónu explive.lab jsme podepsali podpisy platnými 25 minut (do 15:28:07) a nikdy je neobnovili. Unbound je hned neodmítl: toleruje odchylku hodin ve výši 10 % doby platnosti podpisu, ale nejméně jednu hodinu (val-sig-skew-min, výchozí hodnota 3600 sekund). Proto v 16:26:19 resolver ještě přijal čerstvou odpověď s příznakem ad a SERVFAIL s EDE 7 se objevil až v 16:32:19, 64 minut po vypršení. Jiné resolvery mají vlastní toleranci, takže vypršené podpisy shazují web ve vlnách, ne všem najednou. Jedinou ochranou je automatické přepodepisování a hlídání data vypršení RRSIG (vidět v dig +dnssec, například 20261124104054).

3. Přechod k poskytovateli DNS bez DNSSEC, starý DS zůstal

Nejčastější případ u majitelů webů: doména přejde k novému poskytovateli DNS (nové záznamy NS), ale DS od předchozího poskytovatele zůstane u registrátora. Nový poskytovatel servíruje zónu nepodepsanou, nadřazená zóna však dál tvrdí, že podepsaná být musí. Porovnali jsme dvě pořadí kroků na stejných zónách (TTL delegace i DS 300 sekund):

moved.lab (DS left in place)
15:15:05 NS switched to the new host without DNSSEC, DS untouched
15:19:12 SERVFAIL  EDE 9 (DNSKEY Missing)
15:22:02 DS removed in the "registry"
15:23:53 SERVFAIL  (resolver still holds the cached DS)
15:24:13 NOERROR 198.51.100.20

moved2.lab (DS removed first)
15:15:05 DS removed, old NS kept
15:19:12 NOERROR 192.0.2.10 without ad
15:20:31 NS switched to the new host
15:24:13 NOERROR 198.51.100.20, no SERVFAIL at any point

Špatné pořadí způsobilo 5 minut SERVFAIL, z toho přes 2 minuty už po odstranění DS: resolver věřil DS uloženému v cache, dokud nevypršelo jeho TTL. Správné pořadí nezpůsobilo žádné chyby; návštěvníci jen několik minut dostávali neověřené odpovědi. Naše TTL bylo 300 sekund; v .com žije DS 24 hodin, takže zapomenutý DS po přechodu může pro validující resolvery znamenat až den výpadku.

Jak odlišit poruchu DNSSEC od jiných problémů s DNS

Požádejte resolver, aby validaci vynechal, volbou +cd (checking disabled). SERVFAIL bez ní a normální odpověď s ní znamená, že viníkem je DNSSEC:

$ dig @127.0.0.1 www.moved.lab A +dnssec
;; status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (validation failure <www.moved.lab. A IN>: No DNSKEY record from 127.0.22.20 for key moved.lab. while building chain of trust)
$ dig @127.0.0.1 www.moved.lab A +cd
;; status: NOERROR
;; flags: qr rd ra cd
www.moved.lab.  245 IN A 198.51.100.20

SERVFAIL i s +cd ukazuje jinam: na nedostupné servery nebo delegaci mířící na špatné místo. Tyto případy rozebírají naše návody o tom, jak dlouho trvá propagace DNS, a o DNS záznamech.

Velikost odpovědi: ECDSA P-256 proti RSA 2048

Podpisy každou odpověď zvětšují a na algoritmu záleží. Podepsali jsme dvě stejné zóny: good.lab algoritmem 13 (ECDSA P-256, KSK i ZSK) a rsa.lab algoritmem 8 (RSA/SHA-256, oba klíče 2048 bitů) a změřili velikost autoritativní odpovědi (dig +norec, řádek MSG SIZE).

Podpisy RSA dělají odpovědi 1,9-2,8krát větší než ECDSA. Všechny naše odpovědi se vešly do 1232 bajtů (běžná velikost bufferu EDNS), ale zóny RSA s dalšími klíči během výměny klíče se k této hranici přibližují a velké odpovědi přes UDP se častěji ztrácejí a opakují přes TCP. Doporučení IETF: RFC 8624 (v listopadu 2025 nahrazené RFC 9904, které přebírá stejné úrovně požadavků) uvádí algoritmy 8 a 13 jako MUST pro podepisování, Ed25519 (15) jako RECOMMENDED a RSA/SHA-1 (5 a 7) jako NOT RECOMMENDED. Pro záznamy DS je SHA-256 (typ 2) povinný a SHA-1 (typ 1) zakázaný. Pokud vám poskytovatel DNS dává na výběr, zvolte algoritmus 13.

Kolik domén a resolverů používá DNSSEC

• Resolvery. APNIC naměřil, že po výměně kořenového klíče 11. října 2026 vzrostl podíl uživatelů za resolvery validujícími DNSSEC z 39,7 % na 40,6 % (Geoff Huston, blog APNIC, 21. 10. 2026, anglicky). Porucha DNSSEC tedy zasáhne zhruba dva z pěti návštěvníků, ne všechny.
• Domény .cz. Registr CZ.NIC uvádí na nic.cz 1 068 873 domén zabezpečených technologií DNSSEC z 1 620 443 registrovaných, tedy 66 % (ověřeno 10. 11. 2026).
• Domény .nl. SIDN uvádí přes 3,3 milionu podepsaných domén z více než 6 milionů (sidn.nl, 10. 11. 2026).
• TTL záznamu DS v registrech (jak dlouho čekat po odstranění DS): 86400 sekund (24 hodin) v .com (cloudflare.com na a.gtld-servers.net); národní zóny mohou mít kratší, například 10801 sekund (asi 3 hodiny) v .ua (hostmaster.ua a cctld.ua na in1.ns.ua). Všechny tři příklady používají algoritmus 13.

Když X, udělejte Y

Kontrolní seznam před změnou poskytovatele DNS

1. Zjistěte, zda existuje DS: dig DS example.com +short. Prázdný výstup znamená, že DNSSEC je vypnutý, a můžete přejít jako obvykle.
2. Zjistěte TTL záznamu DS ve své zóně (dig DS example.com, druhý sloupec; 86400 v .com).
3. Smažte DS u registrátora a ověřte, že dig DS example.com +short už nic nevrací.
4. Počkejte TTL záznamu DS s rezervou (u .com celý den). Web dál funguje, jen bez ad.
5. Teprve teď změňte DNS servery domény a počkejte na TTL delegace.
6. Zapněte podepisování u nového poskytovatele DNS, přidejte nový DS a zkontrolujte příznak ad.
7. Pokud plánujete také převod domény k jinému registrátorovi, zeptejte se nejdřív obou registrátorů, co se stane s DS, a nedělejte obě změny ve stejný den.

Časté otázky

Potřebuje běžný web DNSSEC?

Chrání vaše návštěvníky před podvrženými odpověďmi DNS a je nutný pro DANE u pošty. Pokud váš poskytovatel DNS podepisuje automaticky a při přechodu nezapomenete na DS, vyplatí se ho zapnout. Pokud ne, nechtěné odříznutí 40 % uživatelů je reálnější riziko než útok.

Zpomaluje DNSSEC web?

Odpovědi se zvětší: v našem testu 2,5-3krát s ECDSA a 5-6krát s RSA. Validaci provádí resolver a klíče se ukládají do cache, takže rychlost načítání stránek se téměř nemění. Doby načítání stránek jsme neměřili.

Proč se mi web otevírá, ale kolegům ne?

Váš resolver možná nevaliduje nebo má ještě v cache staré klíče, jako v našem testu s klíčem. Porovnejte dig example.com @1.1.1.1 s dig example.com @1.1.1.1 +cd: rozdíl ukáže, zda je na vině DNSSEC.

Jak rychle se web vrátí po opravě DS?

Ne dřív, než starý DS vyprší z cache resolverů. V našem testu se resolver s TTL záznamu DS 3600 sekund vzpamatoval 52 minut po opravě, s TTL 300 po 2 minutách. V .com je TTL záznamu DS 24 hodin; Google Public DNS a Cloudflare umožňují doménu ze své cache ručně vymazat.