Da én feil tok ned 16 millioner domener: Lærdom fra .de DNS-utfallet

De fleste av oss tenker ikke på DNS før det slutter å fungere. Og når det skjer? Alt stopper opp.

5. mai 2026 fikk det tyske domeneregisteret DENIC denne erfaringen på den harde måten. Under en rutinemessig DNSSEC-nøkkelrotasjon ble .de-domenene utilgjengelige i omtrent tre timer. Validerende resolvere over hele verden kastet "bogus"-feil som confetti på en defekt fest.

Den tekniske årsaken var én feil i egenutviklet rotasjonsprogramvare. Men det virkelig interessante – og det enhver utvikler og infrastruktur-ingeniør bør merke seg – er hvorfor dette skjedde.

Hva som skjedde

DNSSEC-signeringen for .de-domener kjører på en blanding av standard programvare (Knot resolver) og egne utviklinger, beskyttet av Hardware Security Modules (HSMer). HSMer fungerer som hvelv for kryptografi – de genererer og lagrer de private nøklene som sikrer DNS-sonen.

Under en rutine-nøkkelrotasjon i mai 2026 oppstod problemet. Den egendyrkede "rotasjonsagenten" – programvaren som genererer nøkkelmateriale og distribuerer det til alle HSMer – oppførte seg katastrofalt feil.

Feilen var denne: i stedet for å generere ét nøkkelpar og sende det til alle HSMer, produserte den bittige koden tre separate nøkkelpar – ett til hver HSM. Verre: alle tre parene fikk identisk metadata, inkludert samme key tag (33834).

Resultatet? Da sonen ble publisert, hadde bare én av de tre HSMene den private nøkkelen som matchet den offentlige DNSKEY-posten. Bare omtrent én tredjedel av DNSSEC-signaturene lot seg validere. Resten? Ugyldige. Og i DNSSEC betyr en ugyldig signatur ikke "sannsynligvis greit" – den betyr "falsk."

Hvorfor testingen ikke fanget dette

Dette er der historien blir verdifull for alle som skriver infrastrukturkode.

Feilen i rotasjonsagenten oppstår bare når flere HSMer er tilkoblet. Problemet: testmiljøet hadde én HSM på én lokasjon.

Med én HSM i testoppsettet er resultatet identisk uansett om koden genererer "ett nøkkelpar per HSM" eller "ett nøkkelpar for alle HSMer". Den feilaktige koden besto alle tester fordi testmiljøet ikke reflekterte virkeligheten i produksjon.

Dette er et klassisk tilfelle av miljøparitetssvikt – et fenomen enhver utvikler kjenner til i teorien, men som likevel dukker opp i praksis. Testmiljøet var "godt nok" akkurat til det ikke var det lenger.

Monitoreringsparadokset

Her kommer det virkelig frustrerende: DENICs overvåkningssystemer oppdaget faktisk problemet.

Tre separate valideringsverktøy kjørte kontinuerlig og sjekket for manglende eller ikke-validerbare signaturer. Disse systemene gjorde akkurat det de skulle – de identifiserte anomaliene.

Men de genererte varslene ble ikke behandlet riktig. Notifikasjonene ble sendt, men menneskene mottok dem for sent (eller handlet ikke på dem), og den defekte sonen ble publisert i tre kritiske timer.

Dette er et mønster vi ser igjen og igjen: overvåking som oppdager problemer er bare så verdifull som incident response-prosessen som handler på disse oppdagelsene. Du kan ha verdens beste observabilitetsstack, men hvis varsler feiler lydløst eller responsplanene er uklare, flyr du fortsatt blindt.

Noen store resolver-operatører skjønte hva som skjedde og skrudde midlertidig av DNSSEC-validering for .de-domener – altså ba resolvere om å "stole uten å verifisere" for tyske domener. Dette dempet skaden for deres brukere, men viste hvor skjør validitets-antakelsen vår er.

Dominoeffekten: Hvorfor også ikke-validerte domener brøt

Her er en nyansert detalj som gjør denne hendelsen spesielt lærerik: domenene som brøt, brukte nødvendigvis ikke DNSSEC selv.

DNSSEC-validering skjer rekursivt. Når en resolver spør etter et .de-domene, inneholder svaret NSEC3-poster som beviser at visse poster ikke eksisterer i sonen. Disse NSEC3-postene må signeres – og hvis signaturene er ugyldige, flagges hele responsen som mistenkelig.

Så selv om ditt tyske startups domene ikke bruker DNSSEC i det hele tatt, krever delegasjonskjeden som beviser at ditt domene eksisterer fortsatt gyldige signaturer. Når disse valideringsfeilene tok seg opp, ble domener med null egen DNSSEC-konfigurasjon utilgjengelige.

DNSSEC er bare så sterkt som sin svakeste sone. Da .de-sonens signaturer feilet, så validerende resolvere hele TLD-en som kompromittert.

Hva infrastrukturteam bør ta med seg

1. Test i produksjonslignende miljøer

Dette virker opplagt. Det er opplagt. Og likevel skjer det. Hvis koden din oppfører seg annerledes med én HSM versus tre, trenger testmiljøet ditt tre HSMer. Ja, det er dyrere. Ja, det er mer komplekst. Det er fortsatt nødvendig.

2. Test feilmoduser, ikke bare suksessbaner

Kodegjennomgangen misset dette fordi testsenarioene dekket lykkelige utfall. Hva skjer ved nettverkspartisjonering? Når HSMer legges til eller fjernes? Når nøkler blir usynkroniserte? Fiendtlig testing mot egne antakelser er ikke valgfritt.

3. Overvåking uten runbooks er bare støy

Varsler som ingen vet hvordan de skal håndtere – eller som gir alarm klokken 03 uten klare eskaleringsbaner – forhindrer ikke utfall. De dokumenterer dem. Hvert varsel bør ha en tilhørende runbook. Hver runbook bør testes kvartalsvis.

4. Redundans er ikke bare for hardware

DENICs infrastruktur hadde HSMer fordelt på to geografisk atskilte datasentre. Men programvarearkitekturen antok at alle HSMer ville oppføre seg identisk. Ekte redundans betyr å designe for feil i egne antakelser, ikke bare i komponentene.

5. Tenk på sprengkraften

Når du designer kritisk infrastruktur, spør deg selv: hva skjer når dette bryter, og hvor langt sprer skaden seg? .de-hendelsen rammet domener som ikke hadde noe med DNSSEC å gjøre direkte. Det minner oss om at i distribuertesystemer flyter avhengigheter i uventede retninger.

Den gode nyheten

DENIC håndterte dette med beundringsverdig åpenhet. Den endelige rapporten detaljerte nøyaktig hva som gikk galt, hvorfor eksisterende sikkerhetstiltak feilet, og konkrete tiltak som implementeres – inkludert forbedrede kodegjennomgangsprosesser og styrket incident response-protokoller.

DNSSEC-økosystemet lærer av disse hendelsene. Hvert store utfall – hvert .de, hvert Dyn, hver Cloudflare-hikke – lærer oss noe om å bygge mer robust infrastruktur. Nøkkelen er faktisk å anvende disse lærdomene.

Konklusjonen: DNS er internettets usungne helt helt til det ikke er det. .de-utfallet i mai 2026 minner oss om at selv modne, godt finansierte operasjoner med flere beskyttelseslag kan ydmykes av én feil på rett sted til feil tid.

For utviklere og infrastrukturteam handler det ikke om frykt – det handler om årvåkenhet. Test det du sender ut. Overvåk det du tester. Og anta aldri at testmiljøet ditt perfekt matcher produksjon.

For når DNS bryter, bryter alt. Og lærdommen koster alltid mer jo lenger ned i stacken du oppdager den.