När en enda bugg knäckte 16 miljoner domäner: Lärdomar från .de-kraschen

Låt oss vara ärliga: de flesta av oss tänker inte på DNS förrän det slutar fungera. Och när det händer? Då slutar allt fungera.

Den 5 maj 2026 fick den tyska domänregistratorn DENIC lära sig den hårda vägen – mitt under en rutinmässig DNSSEC-nyckelrotation. I ungefär tre timmar blev det en lotterifråga att komma åt .de-domäner. Vissa fungerade, de flesta gjorde det inte, och validerande resolvers världen över spottade ut "ogiltig"-fel som konfetti på en trasig fest.

Den tekniska grundorsaken? Ett enda fel i en anpassad programvara för nyckelrotation. Men det är i varför-delen som historien blir riktigt intressant – och där varje utvecklare och infrastrukturingenjör bör hänga med.

Vad som faktiskt hände

DNSSEC-signeringsinfrastrukturen för .de-domäner bygger på en kombination av standardprogram (Knot resolver) och egenutvecklade lösningar, allt drivet genom Hardware Security Modules (HSM:er). Tänk på HSM:er som ultradyra kryptografiska kassavalv som genererar och förvarar de privata nycklarna som skyddar DNS-zonen.

Under en rutinmässig nyckelrotation i maj 2026 såg den anpassade "rotationsagenten" – programvaran som ansvarar för att generera nyckelmaterial och distribuera det till alla HSM:er – ut att fungera. Men den gjorde något subtilt och katastrofalt.

Problemet: istället för att generera en nyckelpar och distribuera den till alla HSM:er, genererade den buggiga koden tre separata nyckelpar – ett för varje HSM. Till råga på allt fick alla tre paren identisk metadata, inklusive samma nyckel-tag (33834).

Resultatet? När zonen publicerades hade bara en av de tre HSM:erna den privata nyckeln som matchade den publika DNSKEY-posten. Det betydde att bara ungefär en tredjedel av DNSSEC-signaturerna kunde valideras. Resten? Ogiltiga. Och i DNSSEC betyder en ogiltig signatur inte "förmodligen okej" – den betyder "fulspel."

Varför testerna inte fångade detta

Här blir historien riktigt värdefull för alla som skriver infrastrukturoprogramvara.

Rotationsagentens bugg visade sig bara när flera HSM:er var anslutna. Här är grejen: testmiljön bestod av en enda HSM på en enda plats.

När du bara har en HSM i din testmiljö producerar "en nyckelpar per HSM" och "en nyckelpar för alla HSM:er" identiska resultat. Den felande koden klarade alla tester eftersom testmiljön inte speglade produktionsverkligheten.

Det här är ett klassiskt fall av miljöparitetsmisslyckande – ett fenomen varje utvecklare känner till i teorin men som vi av någon anledning ändå stöter på i praktiken. Testmiljön var "tillräckligt bra" ända tills den inte var det.

övervakningsparadoxen

Här är den riktigt frustrerande delen: DENIC:s övervakningssystem upptäckte faktiskt problemet.

Tre separata valideringsverktyg kördes kontinuerligt och letade efter saknade eller icke-validerbara signaturer. Dessa system gjorde exakt vad de var konstruerade för – de identifierade avvikelserna.

Men de genererade varningarna behandlades inte korrekt. Aviseringarna skickades, människorna tog inte emot dem i tid (eller agerade inte på dem), och den trasiga zonen fortsatte publiceras i tre kritiska timmar.

Det här är ett mönster vi sett om och om igen: övervakning som upptäcker problem är bara så värdefull som incidenthanteringsprocessen som agerar på dessa upptäckter. Du kan ha den bästa observabilitetsstacken i världen, men om varningar tyst misslyckas eller responsmanualer är otydliga, är du fortfarande blind.

Vissa stora resolver-operatörer förstod vad som hände och inaktiverade tillfälligt DNSSEC-validering för .de-domäner – i praktiken instruerade sina resolvers att "lita men inte verifiera" för tyska domäner. Det mildrade skadan för deras användare men belyste hur bräckliga våra valideringsantaganden kan vara.

Dominoeffekten: Varför icke-validerade domäner också gick sönder

Här är en finess som gör denna incident särskilt lärorik: domänerna som gick sönder använde inte nödvändigtvis DNSSEC själva.

DNSSEC-validering sker rekursivt. När en resolver frågar efter en .de-domän inkluderar svaret NSEC3-poster som bevisar att vissa poster inte finns i zonen. Dessa NSEC3-poster måste signeras – och om dessa signaturer är ogiltiga flaggas hela svaret som misstänkt.

Så även om din tyska startup inte använder DNSSEC alls, kräver delegationskedjan som bevisar att din domän existerar fortfarande giltiga signaturer. När dessa valideringsfel fortsatte att rasa neråt blev domäner med noll DNSSEC-konfiguration själva oupplösbara.

DNSSEC är bara så stark som dess svagaste zon. När .de-zonens signaturer misslyckades såg validerande resolvers hela TLD:n som komprometterad.

Vad infrastrukturlag bör ta med sig

1. Testa i produktionsliknande miljöer

Det låter självklart. Det är självklart. Och ändå händer det. Om din kod beter sig annorlunda med en HSM kontra tre, behöver din testmiljö tre HSM:er. Ja, det är dyrare. Ja, det är mer komplext. Det är fortfarande nödvändigt.

2. Felmoder bör testas, inte bara lyckade scenarier

Kodgranskningsprocessen missade detta eftersom testspecifikationerna täckte glada vägar. Vad händer vid nätverkspartitioner? När HSM:er läggs till eller tas bort? När nycklar blir osynkade? Adversariell testning mot dina egna antaganden är inte valfritt.

3. Övervakning utan handböcker är bara brus

Varningar som ingen vet hur man agerar på – eller som triggas klockan 03:00 utan tydliga eskaleringsvägar – förhindrar inte avbrott. De dokumenterar dem. Varje varning bör ha en tillhörande handbok. Varje handbok bör testas kvartalsvis.

4. Redundans är inte bara för hårdvara

DENIC:s infrastruktur hade HSM:er distribuerade över två geografiskt separata datacenter. Men programvaruarkitekturen antog att alla HSM:er skulle bete sig identiskt. Sann redundans betyder att designa för misslyckande av dina antaganden, inte bara dina komponenter.

5. Tänk på sprängradien

När du designar kritisk infrastruktur, fråga dig själv: vad händer när detta går sönder, och hur långt sprider sig skadan? .de-incidenten påverkade domäner som inte hade något med DNSSEC direkt att göra. Det är en påminnelse om att beroenden i distribuerade system rör sig i oväntade riktningar.

Den goda nyheten

DENIC hanterade detta med beundransvärd transparens. Den slutgiltiga rapporten detaljerade exakt vad som gick fel, varför befintliga skyddsåtgärder misslyckades, och konkreta åtgärder som implementeras – inklusive förbättrade kodgranskningsprocesser och stärkta incidentresponsp rotokoller.

DNSSEC-ekosystemet lär sig av dessa incidenter. Varje större avbrott – varje .de, varje Dyn, varje molnoperatörs hicka – lär oss något om att bygga mer motståndskraftig infrastruktur. Nyckeln är att faktiskt tillämpa de lärdomarna.

Sammanfattning: DNS är internetts osjungna hjälte ända tills det inte är det. .de-avbrottet i maj 2026 är en påminnelse om att även mogna, välfinansierade operationer med flera skyddslager kan komma på skam av en enda bugg på rätt ställe vid fel tillfälle.

För utvecklare och infrastrukturlag är takeawayen inte rädsla – det är vaksamhet. Testa vad du levererar. Övervaka vad du testar. Och anta aldrig att din testmiljö speglar produktion perfekt.

För när DNS går sönder, går allt sönder. Och lärdomen kostar alltid mer ju längre ner i stacken du upptäcker den.