Zusammenfassung des Abschlussberichts
Am 11. Juni 2026 hat DENIC die abschließende Auswertung des DNS-Ausfalls vom 5. Mai 2026 veröffentlicht. Sie baut explizit auf der ersten Analyse vom 8. Mai 2026 auf und bestätigt deren Angaben vollständig – ergänzt sie aber um den vollständigen technischen Wirkmechanismus, die ausdrücklich ausgeschlossenen Ursachen und einen konkreten Maßnahmenkatalog.
Im Kern: Ein Software-Fehler in einer DENIC-Eigenentwicklung – dem sogenannten Rollover-Agenten – führte im Rahmen eines regulären DNSSEC-Schlüsselwechsels dazu, dass drei statt eines Schlüsselpaars erzeugt wurden, mit identischen Metadaten inklusive desselben Key-Tags. Der reguläre Betrieb war in der Nacht zum 6. Mai vollständig wiederhergestellt; die Gesamtdauer der Beeinträchtigung gibt DENIC mit ca. drei Stunden an.
Hintergrund: Das DENIC-Signiersystem
Der DNSSEC-Signaturprozess für die .de-Zone kombiniert Standardsoftware (Knot) mit Eigenentwicklungen in Verbindung mit Hardware Security Modulen (HSMs). Im April 2026 – nur wenige Wochen vor dem Vorfall – hatte DENIC die dritte Generation dieses Systems seit der DNSSEC-Einführung für .de im Jahr 2011 in Betrieb genommen. Die neue Generation wurde laut Abschlussbericht vorab getestet und extern auditiert.
Das produktive Signiersystem besteht aus mehreren HSMs, verteilt auf zwei geografisch und netztechnisch getrennte Rechenzentren – eine übliche Redundanzmaßnahme. Genau diese Mehrfach-HSM-Architektur ist der Schlüssel zum Verständnis des Fehlers, der im nächsten Abschnitt beschrieben wird.
Root Cause: Ein Schlüsselpaar pro HSM statt eines gemeinsamen
Der Rollover-Agent ist die Eigenentwicklung, die bei einem geplanten Schlüsselwechsel neues Schlüsselmaterial generiert und in alle angeschlossenen HSMs einspielt. So ist es vorgesehen:
1 Schlüsselpaar wird generiert.
Dasselbe Schlüsselpaar wird in alle angeschlossenen HSMs eingespielt.
Ergebnis: Jede HSM kann mit demselben Schlüssel signieren — alle Signaturen sind austauschbar gültig.
Pro angeschlossener HSM wird ein eigenes Schlüsselpaar generiert.
Jedes Schlüsselpaar wird nur in genau die eine HSM eingespielt, für die es erzeugt wurde.
Ergebnis: 3 verschiedene Schlüsselpaare mit identischen Metadaten (Key-Tag 33834) — nur eines passt zum veröffentlichten DNSKEY.
Alle drei so erzeugten Schlüsselpaare enthielten dieselben Identifier, einschließlich des Key-Tags 33834. DENIC stellt dazu explizit klar: „Es lag damit keine klassische Key-Tag-Kollision vor, sondern drei inhaltlich verschiedene Schlüsselpaare mit identischen Metadaten.” Eine Key-Tag-Kollision wäre ein Zufallskonflikt zwischen zwei eigentlich unabhängigen Schlüsseln gewesen — hier handelte es sich um einen systematischen Erzeugungsfehler.
Folgefehler: Warum nur etwa ein Drittel der Signaturen gültig war
Die fehlerhafte Logik des Rollover-Agenten schrieb anschließend einen der drei erzeugten ZSKs (Zone Signing Keys) mit Key-Tag 33834 in die Zone – also in den veröffentlichten DNSKEY-Record. Problem: Nur eine der drei HSMs enthielt den privaten Schlüssel, der zu genau diesem veröffentlichten DNSKEY passte.
In der Praxis bedeutete das: Signaturanfragen, die zufällig von dieser einen HSM bedient wurden, lieferten gültige RRSIGs. Signaturanfragen, die von einer der beiden anderen HSMs bedient wurden, lieferten RRSIGs, die formal vorhanden, aber kryptografisch nicht zum veröffentlichten Schlüssel passend waren – und damit für validierende Resolver als malformed erkennbar.
Da die Lastverteilung auf die drei HSMs in etwa gleich war, waren laut DENIC nur etwa ein Drittel aller RRSIGs der Zone validierbar. Zusätzlich galt: Der SOA-Record muss wegen der Seriennummer bei jeder Zonenänderung neu erzeugt und neu signiert werden – er war im Verlauf des Vorfalls daher teils validierbar, teils nicht, je nachdem, welche HSM den jeweiligen Signing-Lauf bediente.
Warum der Fehler vor der Inbetriebnahme nicht auffiel
Der fehlerhafte Code wurde im Rahmen von Verbesserungen in die Eigenentwicklung aufgenommen, ohne dass die vorhandenen Testszenarien diesen Fehlerfall abdeckten. Der Grund dafür ist struktureller Natur und liegt in der Testumgebung selbst:
Die Testumgebung von DENIC besteht laut Abschlussbericht lediglich aus einem einzigen HSM an einem Standort. Der fehlerhafte Code im Rollover-Agenten entfaltet sein fehlerhaftes Verhalten aber erst beim Zusammenspiel mehrerer angeschlossener HSMs — mit nur einer HSM ist der Unterschied zwischen „ein gemeinsames Schlüsselpaar für alle HSMs” und „ein Schlüsselpaar pro HSM” schlicht nicht beobachtbar, da es in beiden Fällen nur eine HSM gibt, die es erhält. Der Defekt wurde daher weder bei Testläufen noch im „kalten” Parallelbetrieb vor der Inbetriebnahme erkannt.
Dieses Muster ist in der Software-Qualitätssicherung nicht ungewöhnlich: Eine Testumgebung, die in ihrer Topologie nicht der Produktionsumgebung entspricht, kann genau jene Fehlerklassen verdecken, die erst durch das Zusammenspiel mehrerer redundanter Komponenten entstehen.
Warum die ungültige Zone trotz Monitoring veröffentlicht wurde
Die .de-Zone wird über das Registrierungssystem laufend aktualisiert. Wegen ihrer Größe werden Änderungen an den Resource-Record-Sets inkrementell eingepflegt – einzelne Zonenversionen liegen dabei nicht als vollständige Zonendatei vor, die sich einfach als Ganzes prüfen ließe.
DENIC betreibt drei verschiedene, dauerhaft laufende Prüf- und Validierungswerkzeuge, um Anomalien wie fehlende oder nicht validierbare Signaturen zu erkennen. Laut Abschlussbericht haben diese Systeme die Fehler „bestimmungsgemäß detektiert” — die erzeugten Meldungen wurden jedoch nicht korrekt verarbeitet, sodass keine rechtzeitige Intervention erfolgte.
Bemerkenswert: Dies war kein Erkennungsproblem, sondern ein Prozessproblem zwischen Alarm und Reaktion — eine Unterscheidung, die für die Bewertung der angekündigten Maßnahmen wichtig ist.
Was DENIC ausdrücklich ausgeschlossen hat
Die umfassende Auswertung hat folgende naheliegende Alternativ-Ursachen ausdrücklich geprüft und verneint:
Technische und praktische Auswirkungen
Die .de-Zone liefert in großer Mehrheit sogenannte Referral Responses (Delegationsinformationen). Deren Validierbarkeit hängt auch von signierten NSEC3-Records ab — insbesondere dann, wenn bei einer nicht signierten Child-Zone die Abwesenheit eines DS-Records bewiesen werden muss. Genau diese NSEC3-Signaturen waren von dem Fehler betroffen.
Nicht validierbare Signaturen über NSEC3-Records führten dazu, dass Delegationsinformationen von validierenden Resolvern als verdächtig („Bogus”) eingestuft wurden. In der Folge waren auch solche Second-Level-Domains nicht auflösbar, für die gar kein DNSSEC eingesetzt wird — deckt sich mit der in unserer technischen Tiefenanalyse beschriebenen Beobachtung bei blackfort-tec.de. Nicht validierende Resolver lieferten die .de-Zone hingegen anstandslos aus.
DENIC gibt die Gesamtdauer der Einschränkungen mit ca. drei Stunden an. Einige Betreiber großer Resolver hatten währenddessen vorübergehend die DNSSEC-Validierung für .de-Domains ausgesetzt und damit die Auswirkungen für ihre Nutzer abgemildert — DENIC bedankt sich im Bericht ausdrücklich für diese Unterstützung.
Maßnahmen: Was DENIC jetzt ändert
Erste Erkenntnisse — etwa Verbesserungen im Code-Review-Prozess — sind laut Bericht bereits umgesetzt. Der Incident-Response-Prozess und die Kommunikation während einer Störung werden zusätzlich einem Review unterzogen. Kurzfristig kommen fünf konkrete Maßnahmen hinzu:
Erweiterte Alarmierung
Weitere Alarme, aufbauend auf besserer Sichtbarkeit möglicher Fehler bei den dauerhaft laufenden Prüf- und Validierungswerkzeugen, plus Erweiterung relevanter Metriken.
Beschleunigtes Umschaltverfahren
Ein beschleunigtes Verfahren, um im Notfall schneller ein valides Zonen-Backup bereitzustellen.
Teil-Validierung vor Auslieferung
Eine Teil-Validierung der Zone, bevor sie überhaupt ausgeliefert wird — soll genau diese Fehlerklasse künftig vor Veröffentlichung abfangen.
Aussetzung weiterer ZSK-Rollovers
Weitere Zone-Signing-Key-Rollovers werden ausgesetzt, bis Sicherheit im Softwareentwicklungsprozess und Testabdeckung verbessert sind.
Externe Sicherheits- und Prozessanalyse
Eine externe und abschließende Sicherheits- und Prozessanalyse wird durchgeführt — zusätzlich zur internen Auswertung.
Einordnung: Was sich gegenüber der ersten Stellungnahme ändert
Die erste DENIC-Stellungnahme vom 8./10. Mai 2026 — die wir bereits in unseren beiden Mai-Artikeln zitiert haben — nannte bereits „drei statt einem Schlüsselpaar” und „etwa ein Drittel validierbare Signaturen”. Der jetzige Abschlussbericht bestätigt diese Angaben vollständig und ergänzt sie um drei Punkte, die vorher nicht öffentlich bekannt waren:
- →Der genaue Wirkmechanismus: ein Schlüsselpaar pro HSM statt eines gemeinsamen, mit identischen Metadaten — explizit keine Key-Tag-Kollision.
- →Warum der Test versagte: die Testumgebung mit nur einem HSM konnte die Fehlerklasse strukturell nicht abdecken.
- →Warum Monitoring nicht griff: Erkennung funktionierte, Alarmverarbeitung nicht — plus ein konkreter Fünf-Punkte-Maßnahmenplan.
Lessons Learned für Unternehmen
Der Abschlussbericht ist nicht nur für DENIC selbst lehrreich. Drei Übertragungen auf die eigene Infrastruktur und Softwareentwicklung sind naheliegend:
Testumgebungen müssen die Produktionstopologie abbilden
Redundante Komponenten (mehrere HSMs, mehrere Knoten, mehrere Rechenzentren) erzeugen Fehlerklassen, die in einer vereinfachten 1-Instanz-Testumgebung schlicht nicht beobachtbar sind. Wer produktiv mit n Instanzen einer kritischen Sicherheitskomponente arbeitet, sollte auch mit n (oder zumindest n>1) Instanzen testen.
Erkennung ohne verlässliche Alarmverarbeitung ist wirkungslos
DENICs Monitoring hat korrekt funktioniert — der Vorfall ist trotzdem eingetreten, weil die Meldung den richtigen Empfänger nicht rechtzeitig erreichte. Das ist ein Prozess-Audit-Thema für jedes SIEM: Wird jeder kritische Alert tatsächlich zeitnah von jemandem mit Handlungsbefugnis gesehen und bearbeitet?
Partial Validation vor Auslieferung als generelles Muster
DENICs angekündigte Teil-Validierung der Zone vor Auslieferung ist ein Muster, das sich auf jede kritische Konfigurationsänderung übertragen lässt: ein automatisierter Plausibilitäts-Check vor dem Rollout, nicht erst danach per Monitoring.
Fazit: Ein vorbildlich transparenter und lehrreicher Abschlussbericht
DENIC legt mit diesem Abschlussbericht eine ungewöhnlich detaillierte Root-Cause-Analyse vor — inklusive expliziter Benennung des Softwarefehlers, der ausgeschlossenen Alternativ-Ursachen und eines konkreten Maßnahmenplans. Das schafft Vertrauen in den Umgang mit dem Vorfall, ändert aber nichts an der Kernerkenntnis aus unserer Mai-Analyse: Selbst eine korrekt konfigurierte Domain kann durch einen Fehler in der übergeordneten DNSSEC-Vertrauenskette selektiv unerreichbar werden.
Für Unternehmen bleibt die Konsequenz dieselbe wie im Mai: DNS- und DNSSEC-Monitoring gehört in jedes Security Monitoring, unabhängig davon, wie sorgfältig die jeweilige Registry arbeitet. Dieser Vorfall zeigt zugleich, dass selbst eine Registry mit externen Audits und mehrfacher Redundanz an einer Stelle versagen kann, die in keinem Testszenario abgedeckt war.
Häufige Fragen zum DENIC-Abschlussbericht
Was ist die tatsächliche Root Cause des DNS-Ausfalls vom 5. Mai 2026?
War das eine klassische Key-Tag-Kollision?
Warum wurde nur etwa ein Drittel der Signaturen als gültig akzeptiert?
Warum hat das Testsystem diesen Fehler nicht erkannt?
Hatte DENIC keine Überwachung, die das hätte verhindern können?
Wurde ein Angriff oder eine Kompromittierung als Ursache ausgeschlossen?
DNS Security · Beratung
Von der Root-Cause-Analyse zur eigenen Resilienz
Selbst eine Registry mit externen Audits und mehrfacher HSM-Redundanz konnte diesen Fehler nicht verhindern. Unser DNS Resilience Assessment bewertet Ihre Infrastruktur gegen reale Ausfallszenarien – mit regulatorischer Einordnung nach NIS2 und DORA.