Als ein einzelner Bug 16 Millionen Domains lahmlegte: Lehren aus dem .de-DNS-Ausfall

Ehrlich gesagt: DNS denkt niemand, solange es funktioniert. Sobald es das nicht mehr tut? Dann ist plötzlich alles vorbei.

Am 5. Mai 2026 bekam die deutsche Domain-Verwaltung DENIC diese Lektion auf die harte Tour. Bei einer routinemäßigen DNSSEC-Schlüsselerneuerung ging für etwa drei Stunden bei .de-Domains buchstäblich gar nichts mehr. Validierende Resolver auf der ganzen Welt spuckten "bogus"-Fehler aus wie Konfetti auf einer kaputten Party.

Der technische Grund war ein einzelner Fehler in einer selbstentwickelten Software. Aber das Warum hinter diesem Ausfall ist wirklich lehrreich – und hier sollten alle Entwickler und Infrastructure Engineers genau aufpassen.

Was genau passiert ist

Die DNSSEC-Signaturinfrastruktur für .de-Domains setzt auf eine Mischung aus Standardsoftware (Knot Resolver) und eigens entwickelten Komponenten. Alles läuft durch sogenannte HSMs – Hardware Security Modules. Stell dir HSMs wie hochsichere Tresore vor, die private Schlüssel für die DNS-Zone generieren und aufbewahren.

Bei der routinemäßigen Schlüsselerneuerung im Mai 2026 gab das selbstgeschriebene "Rollover-Tool" den Geist auf – subtil, aber verheerend.

Das Problem: Anstatt ein Schlüsselpaar zu generieren und an alle HSMs zu verteilen, erzeugte der fehlerhafte Code drei separate Schlüsselpaare – eines für jeden HSM. Das Fatale: Alle drei Paare bekamen identische Metadaten, einschließlich desselben Key Tags (33874).

Das Ergebnis? Als die Zone veröffentlicht wurde, hatte nur einer der drei HSMs den privaten Schlüssel, der zum öffentlichen DNSKEY-Eintrag passte. Nur etwa ein Drittel der DNSSEC-Signaturen ließen sich validieren. Der Rest? Ungültig. Und bei DNSSEC bedeutet eine ungültige Signatur nicht "vielleicht in Ordnung" – sie bedeutet "Bogus."

Warum die Tests das nicht erkannt haben

Hier wird die Geschichte richtig interessant – und wertvoll für alle, die Infrastructure Code schreiben.

Der Fehler im Rollover-Tool trat nur auf, wenn mehrere HSMs angeschlossen waren. Das Problem: Die Testumgebung bestand aus genau einem HSM an einem einzigen Standort.

Wenn du nur einen HSM im Testsystem hast, erzeugt "ein Schlüsselpaar pro HSM" und "ein Schlüsselpaar für alle HSMs" identische Ergebnisse. Der fehlerhafte Code bestand jeden Test, weil die Testumgebung nicht die Realität der Produktion abbildete.

Das ist ein klassischer Fall von Environment Parity Failure – ein Phänomen, das jeder Entwickler theoretisch kennt, aber das trotzdem immer wieder vorkommt. Die Testumgebung war "gut genug" – genau bis zu dem Moment, als sie es nicht mehr war.

Das Monitoring-Paradox

Hier wird es richtig frustrierend: DENICs Monitoring-Systeme haben das Problem tatsächlich erkannt.

Drei separate Validierungstools liefen kontinuierlich und prüften auf fehlende oder nicht validierbare Signaturen. Diese Systeme taten genau das, wofür sie gebaut waren – sie identifizierten die Anomalien.

Aber die generierten Alarme wurden nicht korrekt verarbeitet. Die Benachrichtigungen wurden ausgelöst, aber die zuständigen Menschen bekamen sie nicht rechtzeitig mit – oder handelten nicht schnell genug. Die fehlerhafte Zone wurde drei kritische Stunden lang weiter veröffentlicht.

Das ist ein Muster, das wir immer wieder sehen: Monitoring, das Probleme erkennt, ist nur so viel wert wie der Incident-Response-Prozess, der auf diese Erkenntnisse reagiert. Du kannst den besten Observability-Stack der Welt haben – wenn Alarme ins Leere laufen oder Reaktionsanleitungen unklar sind, fliegst du trotzdem blind.

Einige große Resolver-Betreiber erkannten, was passierte, und deaktivierten vorübergehend die DNSSEC-Validierung für .de-Domains. Im Grunde sagten sie ihren Resolvern: "Vertrauen ohne Überprüfen" für deutsche Domains. Das begrenzte den Schaden für ihre Nutzer – zeigte aber auch, wie fragil unsere Validierungsannahmen sein können.

Der Dominoeffekt: Warum auch Nicht-validierte Domains brachen

Hier ist ein Detail, das diesen Vorfall besonders lehrreich macht: Die Domains, die brachen, nutzten nicht unbedingt selbst DNSSEC.

DNSSEC-Validierung funktioniert rekursiv. Wenn ein Resolver eine .de-Domain abfragt, enthält die Antwort NSEC3-Records, die beweisen, dass bestimmte Einträge in der Zone nicht existieren. Diese NSEC3-Records müssen signiert sein – und wenn diese Signaturen ungültig sind, wird die gesamte Antwort als verdächtig markiert.

Selbst wenn deine deutsche Startup-Domain überhaupt kein DNSSEC nutzt: Die Delegationskette, die beweist, dass deine Domain existiert, erfordert trotzdem gültige Signaturen. Als diese Validierungsfehler sich ausbreiteten, wurden Domains ohne eigene DNSSEC-Konfiguration unauflösbar.

DNSSEC ist nur so stark wie seine schwächste Zone. Wenn die Signaturen der .de-Zone fehlschlagen, sieht die gesamte TLD für validierende Resolver kompromittiert aus.

Was Infrastructure Teams mitnehmen sollten

1. Teste in produktionsnahen Umgebungen

Das klingt offensichtlich. Es ist offensichtlich. Und passiert trotzdem. Wenn dein Code sich mit einem HSM anders verhält als mit dreien, braucht deine Testumgebung drei HSMs. Ja, das ist teurer. Ja, das ist komplexer. Es bleibt trotzdem notwendig.

2. Auch Fehlerszenarien testen, nicht nur Erfolgspfade

Der Code-Review-Prozess hat das übersehen, weil die Testszenarien nur den "Happy Path" abdeckten. Was passiert bei Netzwerkpartitionierung? Wenn HSMs hinzukommen oder wegfallen? Wenn Schlüssel außer Takt geraten? Adversarial Testing gegen die eigenen Annahmen ist keine Option.

3. Monitoring ohne Runbooks ist nur Rauschen

Alarme, bei denen niemand weiß, wie man darauf reagieren soll – oder die um 3 Uhr nachts ohne klare Eskalationswege losgehen – verhindern keine Ausfälle. Sie dokumentieren sie. Jeder Alarm braucht ein zugehöriges Runbook. Und jedes Runbook sollte vierteljährlich getestet werden.

4. Redundanz ist nicht nur für Hardware gedacht

DENICs Infrastruktur hatte HSMs in zwei geografisch getrennten Rechenzentren. Aber die Software-Architektur ging davon aus, dass alle HSMs sich identisch verhalten. Echte Redundanz bedeutet, den Ausfall seiner Annahmen zu designen – nicht nur den Ausfall von Komponenten.

5. Den Blast Radius bedenken

Wenn du kritische Infrastruktur entwirfst, frag dich: Was passiert, wenn das bricht, und wie weit reicht der Schaden? Der .de-Vorfall betraf Domains, die gar nichts direkt mit DNSSEC zu tun hatten. Das zeigt: In verteilten Systemen fließen Abhängigkeiten in unerwartete Richtungen.

Die gute Nachricht

DENIC hat diesen Vorfall vorbildlich transparent behandelt. Der abschließende Bericht erklärte genau, was schiefging, warum bestehende Schutzmaßnahmen versagten, und welche konkreten Maßnahmen umgesetzt werden – einschließlich verbesserter Code-Review-Prozesse und verstärkter Incident-Response-Protokolle.

Das DNSSEC-Ökosystem lernt aus solchen Vorfällen. Jeder größere Ausfall – jeder .de-Vorfall, jeder Dyn-Angriff, jeder Cloudflare-Hickup – lehrt uns etwas darüber, widerstandsfähigere Infrastruktur zu bauen. Der Trick ist, diese Lehren auch tatsächlich anzuwenden.

Fazit: DNS ist der unbesungene Held des Internets – solange es nicht versagt. Der .de-Ausfall im Mai 2026 erinnert uns daran, dass auch reife, gut finanzierte Betriebe mit mehreren Schutzschichten von einem einzelnen Bug am falschen Ort zur Rechenschaft gezogen werden können.

Für Entwickler und Infrastructure Teams geht es nicht um Angst – es geht um Wachsamkeit. Teste, was du auslieferst. Überwache, was du testest. Und geh niemals davon aus, dass deine Testumgebung die Produktion perfekt widerspiegelt.

Denn wenn DNS ausfällt, fällt alles aus. Und die Lektion kostet immer mehr, je weiter unten im Stack du sie lernst.