Když jedna chyba položila 16 milionů domén: Poučení z výpadku .de DNS

Upřímně? Většina z nás na DNS nemyslí, dokud se něco nepokazí. A když se pokazí? Pokazí se úplně všechno.

Pátého května 2026 se německý registr DENIC poučil tím nejtěžším způsobem během běžné výměny DNSSEC klíčů. Přibližně tři hodiny bylo přístupování k .de doménám jako hod mincí — některé fungovaly, většina ne, a validující resolvery po celém světě házely chyby „bogus" jako konfety na rozbitém večírku.

Technická příčina? Jediná chyba v custom rollover softwaru. Ale to zajímavé — a to, co by mělo zajímat každého vývojáře a infrastrukturního inženýra — je proč k tomuto výpadku došlo.

Co se vlastně stalo

Podpisová infrastruktura DNSSEC pro .de domény kombinuje standardní software (Knot resolver) s vlastními interními řešeními, vše běží přes Hardware Security Modules (HSM). HSM si představte jako superbezpečné kryptografické trezory, které generují a ukládají privátní klíče chránící DNS zónu.

Během rutinní výměny klíčů v květnu 2026 selhala custom „rollover agent" — software zodpovědný za generování klíčového materiálu a jeho distribuci napříč všemi HSM — subtlním, ale katastrofálním způsobem.

Problém byl ten, že místo generování jednoho páru klíčů a jeho distribuce na všechny HSM buggy kód vygeneroval tři samostatné páry klíčů — jeden pro každý HSM. Horší bylo, že všechny tři páry měly identická metadata, včetně stejného key tagu (33834).

Výsledek? Když se zóna publikovala, pouze jeden ze tří HSM měl privátní klíč odpovídající veřejnému DNSKEY záznamu. Znamenalo to, že přibližně jen třetina DNSSEC podpisů se dala validovat. Zbytek? Neplatný. A v DNSSEC neplatný podpis neznamená „pravděpodobně v pořádku" — znamená „bogus."

Proč to testy neodhalily

Tady příběh dostává skutečnou hodnotu pro každého, kdo píše infrastrukturní kód.

Chyba rollover agenta se projeví pouze když jsou připojeny multiple HSM. Tady je ten háček: testovací prostředí se skládalo z jednoho HSM na jednom místě.

Když máte v testovacím setupu pouze jeden HSM, generování „jeden pár klíčů na HSM" a „jeden pár klíčů pro všechny HSM" dává identické výsledky. Chybný kód prošel všemi testy, protože testovací prostředí neodpovídalo produkční realitě.

Klasický případ environment parity failure — fenomén, o kterém ví každý vývojář teoreticky, ale v praxi se s ním stejně setkává. Testovací prostředí bylo „dost dobré" přesně do té doby, než nebylo.

Paradox monitoringu

Tady přichází ta opravdu frustrující část: DENIC monitoringové systémy ve skutečnosti problém detekovaly.

Tři samostatné validační nástroje běžely kontinuálně a kontrolovaly chybějící nebo nevalidovatelné podpisy. Tyto systémy dělaly přesně to, co měly — identifikovaly anomálie.

Ale vygenerované alerty se nezpracovaly správně. Notifikace se odeslaly, lidé je včas nepřečetli (nebo na ně nezareagovali), a broken zóna se publikovala další tři kritické hodiny.

Toto je vzorec, který vidíme znovu a znovu: monitoring, který detekuje problémy, má hodnotu pouze takovou, jakou má incident response proces, který na tyto detekce reaguje. Můžete mít ten nejlepší observability stack na světě, ale pokud alerty tiše selhávají nebo response playbooks jsou nejasné, pořád létáte naslepo.

Někteří velcí operátoři resolverů přišli na to, co se děje, a dočasně vypnuli DNSSEC validaci pro .de domény — v podstatě řekli svým resolverům „věř, ale neověřuj" pro německé domény. Tím zmírnili škody pro své uživatele, ale zároveň ukázali, jak křehké jsou naše validační předpoklady.

Domino efekt: Proč selhaly i domény bez vlastní validace

Tady je detail, který dělá tento incident obzvlášť poučným: domény, které přestaly fungovat, nutně nemusely samy DNSSEC používat.

DNSSEC validace probíhá rekurzivně. Když resolver dotazuje .de doménu, odpověď obsahuje NSEC3 záznamy, které dokazují, že určité záznamy v zóně neexistují. Tyto NSEC3 záznamy musí být podepsané — a pokud jsou tyto podpisy neplatné, celá odpověď se označí jako podezřelá.

Takže i když vaše německá startup doména vůbec DNSSEC nepoužívá, delegation chain dokazující existenci vaší domény stále vyžaduje platné podpisy. Když tyto validační chyby kaskádovitě dopadaly, domény s nulovou vlastní DNSSEC konfigurací se staly neřešitelnými.

DNSSEC je silný jen tak, jak silný je jeho nejslabší článek. Podpisy .de zóny selhaly, takže celé TLD vypadalo kompromitovaně pro validující resolvery.

Co si z toho infrastrukturní týmy odnést

1. Testujte v prostředí podobném produkci

Zdá se to jako samozřejmost. A je to samozřejmost. A přesto se to děje. Pokud se váš kód chová jinak s jedním HSM než se třemi, vaše testovací prostředí potřebuje tři HSM. Ano, je to dražší. Ano, je to komplexnější. Pořád je to nutné.

2. Testujte failure módy, ne jen happy paths

Proces code review tuto chybu minul, protože testovací scénáře pokrývaly jen optimistické cesty. Co se stane při network partition? Když se HSM přidají nebo odeberou? Když se klíče synchronizují špatně? Adversarial testing proti vlastním předpokladům není volitelný.

3. Monitoring bez runbooků je jen šum

Alerty, na které nikdo neví jak reagovat — nebo které přijdou ve tři ráno bez jasných eskalačních cest — nepreventují výpadky. Dokumentují je. Každý alert by měl mít asociovaný runbook. Každý runbook by měl být kvartálně testován.

4. Redundance není jen o hardwaru

DENIC infrastruktura měla HSM distribuované ve dvou geograficky oddělených datových centrech. Ale softwarová architektura předpokládala, že všechny HSM se budou chovat identicky. True redundancy znamená navrhovat pro selhání vlastních předpokladů, ne jen komponent.

5. Zvažte blast radius

Když navrhujete kritickou infrastrukturu, zeptejte se sami sebe: co se stane, když to selže, a jak daleko škody dosáhnou? Incident .de ovlivnil domény, které s DNSSEC neměly nic společného. Připomínka, že v distributed systémech závislosti tečou nečekanými směry.

Ta dobrá zpráva

DENIC s tímto incidentem zacházel obdivuhodně transparentně. Finální report podrobně popsal, co přesně selhalo, proč existující ochranné mechanismy selhaly, a konkrétní opatření, která se implementují — včetně vylepšených code review procesů a posílených incident response protokolů.

DNSSEC ekosystém se z těchto incidentů učí. Každý velký výpadek — každý .de, každý Dyn, každý Cloudflare hiccup — nás něco učí o stavění resilientnější infrastruktury. Klíčové je tyto lekce skutečně aplikovat.

Závěr: DNS je internetový neprávem opomíjený hrdina až do chvíle, kdy přestane být. Výpadek .de v květnu 2026 je připomínkou, že i zralé, dobře financované operace s mnoha vrstvami ochrany může položit jediná chyba na správném místě ve špatný čas.

Pro vývojáře a infrastrukturní týmy není pointa ve strachu — je ve vigilance. Testujte to, co shipujete. Monitorujte to, co testujete. A nikdy nepředpokládejte, že vaše testovací prostředí dokonale odráží produkci.

Protože když DNS selže, selže všechno. A lekce stojí tím víc, čím později ve stacku se ji naučíte.