Når DNSSEC-opdateringer går galt: Lektioner fra .de-nedbruddet

Har du nogensinde lavet en opdatering på produktionssystemet midt om natten? Alt tester fint i simuleringsrunder, men så sker det alligevel. Præcis det ramte .de-registret den 5. maj 2026.

I tre timer var tusindvis af .de-hjemmesider utilgængelige. Ikke fordi domænerne forsvandt, men fordi DNSSEC-sikkerheden selv knækkede dem.

Den perfekte storm: Tech plus procesfejl

.de-registret havde brugt måneder på et nyt DNSSEC-signeringssystem – tredje generation. Det var testet. Auditeret. Sikkerhedsmæssigt vandtæt.

Så gik det galt: Systemet spytter tre forskellige kryptografiske nøglepar ud i stedet for ét. Kun én nøgle blev publiceret. Resultatet? En total mismatch mellem signering og det, resolvere forventede.

Teknisk set er det fascinerende. DNSSEC bruger key tags – et fingeraftryk af den offentlige nøgle. Alle tre nøgler fik samme tag (33834). De fleste resolvere – omkring to tredjedele – afviste signaturerne, fordi privatnøglen ikke matchede den offentlige.

Problemet spredte sig. Signeringssystemet genskaber SOA-rekorden ved hver zoneændring. Nogle opdateringer gik igennem, andre ikke. Resolver-operatører stod med en rodet, ukendt tilstand.

Hvorfor opdagede monitoringen det ikke?

Jo, det gjorde den. .de kører tre uafhængige valideringsværktøjer, der fanger netop sådanne fejl. Alle tre slog alarm om ugyldige signaturer.

Men ingen reagerede.

Alarmerne blev logget og begravet i produktionsstøjen. Det er ikke tech-problem. Det er procesfejl. Kan ramme enhver med kritisk infrastruktur.

Poenget? Monitoring er kun så stærk som dine responsrutiner. Automatiske alarmer uden ansvar og eskaleringsveje er bare larm.

Kædereaktionen: Hvordan det ramte usignerede domæner

Her bliver det virkelig ødelæggende. DNSSEC beviser ikke kun signaturer. Det beviser også fraværet af dem via NSEC3-rekorder – selv for usignerede domæner.

Med ugyldige signaturer på NSEC3 afviste resolvere hele delegationen til andet-niveau-domæner. Din example.de uden DNSSEC? Alligevel nede, fordi TLD-infrastrukturen var "bogus".

Avancerede sikkerhedseffekter, som få DNS-operatører tænker over – før det sker.

Den menneskelige redning

Et lysglimt: Store resolver-operatører slukkede midlertidigt DNSSEC-validering for .de. Brugere kom tilbage på nettet. Registret takkede offentligt.

Det er internettet i topform. Erfarne folk ved, hvordan man løsner restriktioner under pres. Men det understreger behovet for DNS-veteraner, der kan vægte risici hurtigt.

Lektionerne vi tager med

Til udviklere og DevOps-folk handler det om disse pointer:

1. Test huller findes altid. Auditeret kode med fuld test kan stadig fejle i live. Fejlen med flere nøglepar slap igennem alt.

2. Alarmer uden handling er show. Tre systemer fungerede perfekt. Uden øjeblikkelig opmærksomhed og klare veje? Værdiløse.

3. Kend dine afhængigheder. Usignerede domæner viste, hvor forbundet DNS-sikkerhed er. TLD-ændringer rammer uventet langt ude.

4. Parallel drift er ikke nok. .de kørte det nye system sideløbende. Alligevel dukkede produktionsfejl op.

5. Skriv incident-planer ned. Store resolvere vidste præcis, hvad de skulle gøre. Har du det på din infrastruktur?

Hvad sker der nu?

.de-registret lover dybdegående analyse. Forvent strengere testkrav til DNSSEC, bedre alarmhåndtering og ændringer i zone-generering.

For os på NameOcean eller med eget DNS: Vælg udbydere med solid monitoring og response. Forstå DNSSEC før du tænder det. Hold kontakter til erfarne DNS-folk. Byg alarmer, der rammer on-call direkte.

God nyhed? Efter tre timer var .de tilbage. Infrastrukturen holdt. Fællesskabet fik viden om fejl og genopretning.

Det gør nedbruddet værd.

Har du ramt DNS-nedbrud på din setup? Hvad lærte du? Del din historie – det styrker os alle i at bygge robuste systemer.