Når én fejl tager 16 millioner domæner ned: Læring fra .de DNS-udfaldet

Lad os være ærlige: De fleste af os tænker ikke over DNS, før det går i stykker. Og når det gør? Så går alt i stykker.

Den 5. maj 2026 lærte det tyske domæneregister DENIC denne lektie på den hårde måde under en rutinemæssig DNSSEC-nøglerotation. I cirka tre timer var adgang til .de-domæner som at slå plat eller krone — nogle virkede, de fleste gjorde ikke, og validerende resolvers verden over spyttede "forkerte" fejl ud som konfetti ved en fest, der var gået i stykker.

Den tekniske grundårsag? Én enkelt fejl i skræddersyet rotationssoftware. Men hvorfor dette udfald skete, er hvor det bliver interessant — og hvor enhver udvikler og infrastruktur-ingeniør bør holde øje.

Hvad der faktisk skete

DNSSEC-signerinfrastrukturen for .de-domæner bruger en kombination af standardsoftware (Knot resolver) og brugerudviklede løsninger, alt sammen kørende gennem Hardware Security Modules (HSMs). Tænk på HSMs som ultrasikre kryptografiske bokse, der genererer og opbevarer de private nøgler, der beskytter DNS-zonen.

Under en rutinemæssig nøglerotation i maj 2026 opførte det brugerudviklede "rotationsværktøj" — software ansvarlig for at generere nøglemateriale og distribuere det på tværs af alle HSMs — sig på en subtil, men katastrofal måde.

Her er problemet: I stedet for at generere ét nøglepar og distribuere det til alle tilsluttede HSMs genererede den fejlbehæftede kode tre separate nøglepar — ét til hver HSM. Værre: Alle tre par endte med identisk metadata, inklusive samme nøgletag (33834).

Resultatet? Da zonen blev offentliggjort, havde kun én af de tre HSMs den private nøgle, der matcher den offentlige DNSKEY-post. Det betød, at kun cirka en tredjedel af DNSSEC-signaturerne kunne valideres. Resten? Ugyldige. Og i DNSSEC betyder en ugyldig signatur ikke "sikkert nok" — det betyder "forkert."

Hvorfor test ikke fangede dette

Det er her, historien bliver virkelig værdifuld for alle, der skriver infrastrukturkode.

Rotationsværktøjets fejl manifesterer sig kun, når flere HSMs er tilsluttet. Her er pointen: testmiljøet bestod af én enkelt HSM på én enkelt lokation.

Når du kun har én HSM i dit testsetup, producerer "ét nøglepar per HSM" og "ét nøglepar til alle HSMs" identiske resultater. Den fejlbehæftede kode bestod alle tests, fordi testmiljøet ikke afspejlede produktionsvirkeligheden.

Dette er et klassisk tilfælde af miljøparitetssvigt — et fænomen enhver udvikler kender til i teorien, men alligevel støder på i praksis. Testmiljøet var "godt nok" lige indtil, det ikke var det.

Overvågningsparadokset

Her er den virkelig frustrerende del: DENICs overvågningssystemer opdagede faktisk problemet.

Tre separate valideringsværktøjer kørte kontinuerligt og tjekkede for manglende eller ikke-validerbare signaturer. Disse systemer gjorde præcis, hvad de skulle — de identificerede anomalierne.

Men de genererede alarmer blev ikke behandlet korrekt. Notifikationerne blev sendt, men mennesker modtog dem ikke til tiden (eller handlede ikke på dem), og den fejlbehæftede zone blev ved med at blive offentliggjort i tre afgørende timer.

Dette er et mønster, vi har set igen og igen: overvågning, der opdager problemer, er kun så værdifuld som den incidenthåndteringsproces, der reagerer på disse opdagelser. Du kan have verdens bedste observabilitetsstack, men hvis alarmer fejler lydløst eller responseplaybooks er uklare, flyver du stadig blindt.

Nogle store resolver-operatører regnede ud, hvad der skete, og midlertidigt deaktiverede DNSSEC-validering for .de-domæner — essentially fortælle deres resolvers at "stol men verificer ikke" for tyske domæner. Dette afbødede skaden for deres brugere, men fremhævede hvor skrøbelige vores valideringsantagelser kan være.

Dominoeffekten: Hvorfor ikke-validerede domæner også gik ned

Her er en subtilitet, der gør denne hændelse særligt oplysende: Domænerne, der gik ned, brugte ikke nødvendigvis DNSSEC selv.

DNSSEC-validering sker rekursivt. Når en resolver forespørger et .de-domæne, inkluderer svaret NSEC3-poster, der beviser, at visse poster ikke eksisterer i zonen. Disse NSEC3-poster skal signeres — og hvis disse signaturer er ugyldige, flags hele svaret som mistænkeligt.

Så selvom din tyske startups domæne overhovedet ikke bruger DNSSEC, kræver delegationskæden, der beviser at dit domæne eksisterer, stadig gyldige signaturer. Da disse valideringsfejl kaskadede, blev domæner med nul DNSSEC-konfiguration selv umulige at slå op.

DNSSEC er kun så stærk som dens svageste zone. Da .de-zonens signaturer fejlede, så alle validerende resolvers hele TLD'en som kompromitteret.

Hvad infrastrukturteams bør tage med

1. Test i produktionslignende miljøer

Det virker indlysende. Det er indlysende. Og alligevel sker det. Hvis din kode opfører sig forskelligt med én HSM versus tre, har dit testmiljø brug for tre HSMs. Ja, det er dyrere. Ja, det er mere komplekst. Det er stadig nødvendigt.

2. Fejltilstande bør testes, ikke kun succesveje

Kodegennemgangsprocessen missede dette, fordi testspecifikationerne dækkede glade scenarier. Hvad sker der, når netværket opdeles? Når HSMs tilføjes eller fjernes? Når nøgler kommer ud af synkronisering? Adversarial testing mod dine egne antagelser er ikke valgfrit.

3. Overvågning uden runbooks er bare støj

Alarmer, som ingen ved, hvordan man handler på — eller som affyres kl. 3 om natten uden klare eskalationsstier — forhindrer ikke udfald. De dokumenterer dem. Hver alarm bør have en tilknyttet runbook. Hver runbook bør testes kvartalsvis.

4. Redundans er ikke kun for hardware

DENICs infrastruktur havde HSMs distribueret på tværs af to geografisk adskilte datacentre. Men softwarearkitekturen antog, at alle HSMs ville opføre sig identisk. Ægte redundans betyder at designe til fejl i dine antagelser, ikke kun i dine komponenter.

5. Overvej sprængradius

Når du designer kritisk infrastruktur, så spørg dig selv: Hvad sker der, når dette går i stykker, og hvor langt spreder skaden sig? .de-hændelsen påvirkede domæner, der intet havde at gøre med DNSSEC direkte. Det er en påmindelse om, at afhængigheder i distribuerede systemer flyder i uventede retninger.

De gode nyheder

DENIC håndterede dette med beundringsværdig gennemsigtighed. Den endelige rapport detaljerede præcis, hvad der gik galt, hvorfor eksisterende sikkerhedsforanstaltninger fejlede, og konkrete foranstaltninger, der implementeres — inklusive forbedrede kodegennemgangsprocesser og styrkede incidenthåndteringsprotokoller.

DNSSEC-økosystemet lærer af disse hændelser. Hvert stort udfald — hvert .de, hver Dyn, hver Cloudflare-hikke — lærer os noget om at bygge mere robust infrastruktur. Nøglen er faktisk at anvende de lære.

Bundlinjen: DNS er internettets usynlige helt, indtil det ikke er det. .de-udfaldet i maj 2026 er en påmindelse om, at selv modne, vel-finansierede operationer med multiple beskyttelseslag kan ydmyges af en enkelt fejl det rette sted på det rette tidspunkt.

For udviklere og infrastrukturteams er pointen ikke frygt — det er årvågenhed. Test hvad du sender ud. Overvåg hvad du tester. Og antag aldrig, at dit testmiljø perfekt afspejler produktion.

For når DNS går i stykker, går alt i stykker. Og lektionen koster altid mere, jo længere nede i stacken du lærer den.