Abschließende Auswertung, basierend auf der ersten Analyse vom 8. Mai 2026 sowie der umfassenden Nachuntersuchung
Zusammenfassung
Am 5. Mai 2026 kam es im Zuge eines regulären DNSSEC-Schlüsselwechsels zu einem DNS-Ausfall, der die Erreichbarkeit von .de-Domains für ca. drei Stunden erheblich einschränkte. Ursache war ein Fehler im Software-Code einer Eigenentwicklung, der dazu führte, dass ein Großteil der ausgelieferten DNSSEC-Signaturen nicht validierbar war. Der reguläre Betrieb wurde in der Nacht zum 6. Mai vollständig wiederhergestellt. Die Angaben der ersten Analyse vom 8. Mai 2026 gelten als bestätigt.
Hintergrund: Das Signiersystem
Der DNSSEC-Signaturprozess für DE setzt Standardsoftware (Knot) sowie Eigenentwicklungen in Verbindung mit Hardware Security Modulen (HSMs) ein. Im April 2026 wurde die dritte Generation dieses Systems seit der DNSSEC-Einführung im Jahr 2011 in Betrieb genommen. Die Systeme wurden vorab getestet und extern auditiert. Das eingesetzte Signiersystem besteht aus mehreren HSMs, aufgeteilt auf zwei geographisch und netztechnisch voneinander getrennte Rechenzentren.
Ursache des Ausfalls
Fehlerhafter Code im Rollover-Agenten
Die tatsächliche Ursache war ein Fehler im Software-Code einer Eigenentwicklung, die einen Rollover-Agenten steuert. Dessen Aufgabe ist es, Schlüsselmaterial zu generieren und in alle angeschlossenen HSMs einzuspielen.
Durch den fehlerhaften Code wurde – anstatt ein einziges Schlüsselpaar zu generieren und dieses anschließend in alle HSMs einzuspielen – pro angeschlossenem HSM ein eigenes Schlüsselpaar erzeugt und jeweils in genau eines eingespielt. Alle drei so erzeugten Schlüsselpaare enthielten dabei dieselben Identifier, einschließlich des Key-Tags 33834. Es lag damit keine klassische Key-Tag-Kollision vor, sondern drei inhaltlich verschiedene Schlüsselpaare mit identischen Metadaten.
Als Folgefehler schrieb die weitere Logik einen der drei ZSKs mit Key-Tag 33834 in die Zone. Da jedoch nur eine der drei HSMs den zum veröffentlichten DNSKEY-Record passenden Schlüssel enthielt, waren lediglich die von dieser HSM erzeugten RRSIGs validierbar – in der Praxis also nur etwa ein Drittel aller Signaturen.
Da der SOA-Record mit jeder Zonenänderung wegen der Seriennummer neu erzeugt und damit auch neu signiert werden muss, war dieser im Verlauf des Vorfalls teils validierbar, teils nicht validierbar.
Warum wurde der Fehler nicht vor der Inbetriebnahme erkannt?
Bei der Umsetzung von Verbesserungen wurde der fehlerhafte Code in die Eigenentwicklung aufgenommen, ohne dass die vorhandenen Testszenarien diesen Fehlerfall abdeckten. Die Testumgebung besteht lediglich aus einem einzigen HSM an einem Standort. Dadurch kam der Software-Code des Rollover-Agenten, der sein fehlerhaftes Verhalten erst bei mehreren angeschlossenen HSMs entfaltet, in der Testumgebung nicht vollständig zur Ausführung. Der Defekt wurde daher weder bei Testläufen noch im „kalten" Parallelbetrieb vor der Inbetriebnahme erkannt.
Warum wurde die nicht validierbare Zone veröffentlicht?
Die DE-Zone wird über das Registrierungssystem regelmäßig aktualisiert. Aufgrund der Größe der Zone werden Änderungen an den RRSets inkrementell eingepflegt; einzelne Zonenversionen liegen dabei nicht als vollständige Zonendatei vor. Drei verschiedene dauerhaft laufende Prüf- und Validierungswerkzeuge sind im Einsatz, um Anomalien – einschließlich fehlender oder nicht validierbarer Signaturen – zu erkennen. Diese Systeme haben die Fehler bestimmungsgemäß detektiert; die erzeugten Meldungen wurden jedoch nicht korrekt verarbeitet, sodass keine rechtzeitige Intervention erfolgte.
Ausgeschlossene Ursachen
Die umfassende Auswertung hat folgende mögliche Ursachen ausdrücklich ausgeschlossen:
- Keine Anzeichen auf Kompromittierung oder Angriffe auf das Signiersystem oder andere Infrastruktur der DENIC
- Kein Fehlverhalten im eingesetzten Knot-Nameserver identifiziert
- Kein Fehlverhalten in den verwendeten HSMs identifiziert
- Keine klassische Key-Tag-Kollision
Auswirkungen
Technische Auswirkungen
Die Validierbarkeit von DNS-Antworten hängt bei einer TLD-Zone, die in großer Mehrheit „Referral Responses" (Delegationsinformationen) liefert, auch von signierten NSEC3-Records ab – insbesondere dann, wenn bei einer nicht signierten Child Zone die Abwesenheit eines DS-Records nachgewiesen werden muss.
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. Nicht validierende Resolver lieferten die .de-Zone hingegen anstandslos aus.
Auswirkungen auf Nutzer und Dauer
Die Einschränkungen bei der Erreichbarkeit von .de-Domains dauerten ca. drei Stunden an. Einige Betreiber großer Resolver hatten vorübergehend die DNSSEC-Validierung für DE-Domains ausgesetzt und damit die Auswirkungen für ihre Nutzer abgemildert. DENIC bedankt sich ausdrücklich für diese Unterstützung.
Maßnahmen
Im Rahmen der umfassenden Analyse und Auswertung haben sich Maßnahmen ergeben, die sowohl den Softwareentwicklungsprozess als auch den konkreten DNS-Betrieb betreffen. Erste Erkenntnisse, wie z.B. Verbesserungen im Code Review Prozess, wurden bereits umgesetzt. Darüber hinaus werden der Incident-Response-Prozess und die Kommunikation während einer Störung einem Review unterzogen und entsprechend angepasst.
Kurzfristig werden unter anderem folgende Maßnahmen umgesetzt:
- Erweiterte Alarmierung: Einrichten weiterer Alarme, aufbauend auf einer besseren Sichtbarkeit möglicher Fehler (u. a. bei den dauerhaft laufenden Prüf- und Validierungswerkzeugen) sowie die Erweiterung relevanter Metriken.
- Beschleunigtes Umschaltverfahren: Einrichten eines beschleunigten Verfahrens, um im Notfall schneller ein valides Zonen-Backup bereitzustellen.
- Teil-Validierung vor Auslieferung: Einrichten einer Teil-Validierung der Zone vor der Auslieferung.
- Aussetzung weiterer ZSK-Rollovers: Aussetzen eines weiteren ZSK-Rollovers bis zum Abschluss weitergehender Maßnahmen, darunter die Erhöhung der Sicherheit im Softwareentwicklungsprozess sowie die Verbesserung der Testumgebung zur Erreichung einer höheren Testabdeckung.
- Externe Sicherheits- und Prozessanalyse: Durchführung einer externen und abschließenden Sicherheits- und Prozessanalyse.
