DENIC-Analyse zum .de-DNS-Ausfall: drei Schlüsselpaare statt einem
Ein Software-Fehler in DENICs eigenem Code führte am 5. Mai 2026 dazu, dass drei HSMs jeweils ein eigenes Schlüsselpaar erzeugten, obwohl nur eines gemeinsam genutzt werden sollte. DENIC hat die Ursache am 11. Mai im eigenen Blog technisch aufgearbeitet.
Inhalt dieses Beitrags
Was ist neu
DENIC (die Genossenschaft, die die deutsche Top-Level-Domain .de verwaltet) hat am 11. Mai 2026 eine technische Analyse des DNS-Ausfalls vom 5. Mai 2026 im eigenen Blog veröffentlicht. Sie beantwortet die Frage, die in unserem Hauptartikel zum Vorfall noch offen war: welche der drei Schichten (privates Schlüsselmaterial, Signier-Code, Verteilung) die ungültigen Signaturen erzeugt hat.
Der Auslöser war ein Fehler im DENIC-eigenen Code: statt ein einziges Schlüsselpaar zu erzeugen und auf die drei produktiven HSMs (Hardware Security Modules, manipulationssichere Spezialgeräte zur Schlüsselverwaltung) zu verteilen, generierte die Eigenentwicklung "gleich drei verschiedene Schlüsselpaare", eines pro HSM. Alle drei trugen denselben Key Tag 33834 (Key Tag = kurze Kennnummer, die einen DNSSEC-Schlüssel identifiziert), und das DNSKEY-Set (die Sammlung veröffentlichter Schlüssel einer Zone) veröffentlichte nur einen der drei öffentlichen Schlüssel. Damit ließen sich rund zwei Drittel der RRSIGs (RRSIG = die kryptografische Signatur über einen DNS-Eintrag), die danach in der Zone signiert wurden, gegen das publizierte Schlüsselmaterial nicht validieren.
DENIC nennt drei begünstigende Faktoren: ein "fehlerhaftes Stück Code in die Eigenentwicklung aufgenommen, das durch die Testszenarien nicht vollständig abgedeckt wurde", "drei verschiedene dauerhaft laufende Prüf- und Validierungswerkzeuge", die zwar Alarme erzeugt haben, deren Meldungen aber "nicht korrekt verarbeitet" wurden, sowie ein kalter Parallelbetrieb (Mitlauf des neuen Systems ohne produktive Wirkung) vor der Inbetriebnahme, der die Fehlerklasse nicht aufgedeckt hat.
Für wen ist das? Für Domain- und DNS-Verantwortliche, die den .de-Vorfall einordnen wollen.
Was sich praktisch ändert
Die im Hauptartikel beschriebene DNSSEC-Logik (DNSSEC = kryptografische Absicherung des Domain-Namensystems gegen gefälschte Antworten) bleibt unverändert: validierende Resolver (Auflösungsserver, die Signaturen prüfen) mussten die Antworten als bogus (ungültig) verwerfen, der Rollback (Rücksetzen) auf den vorherigen DNSKEY-Stand war die richtige Behebung. Neu ist die Lehre für jeden DNSSEC-Betreiber, der mehrere HSMs nutzt: die Schlüsselgenerierung muss nachweisbar an einer einzigen Stelle stattfinden und das Material muss anschließend in die HSMs eingespielt werden. Wer in jeder HSM-Instanz "ein Schlüsselpaar erzeugen" als Standardpfad fährt, hat denselben Bug latent in der Pipeline (Verarbeitungskette).
Für Dernium Watch nehmen wir eine Erweiterung der DNSSEC-Beobachtung vor: nicht nur RRSIG-Validität gegen das publizierte DNSKEY-Set prüfen, sondern auch die früheste RRSIG-Ablaufzeit über die Kette mitführen, um auslaufende Signaturen früh zu erkennen. Eine zusätzliche Beobachtung der Signatur-Vielfalt je Key-Tag bei Mehrfachsigner-Setups steht auf der Roadmap, ist aber noch nicht aktiv.
Einordnung
Die Eskalation aus einem Code-Fehler heraus war kein Versagen von DNSSEC, sondern ein Versagen der Test-Strategie: drei Validatoren haben den Defekt erkannt, ihre Meldung kam aber nicht in einer eskalationsfähigen Form an. DENIC kündigt weitere technische Details an, sobald die Auswertungen abgeschlossen sind.
Häufige Fragen
Waren .de-Domains während des Vorfalls nicht erreichbar?
Für Nutzer mit einem prüfenden (validierenden) Resolver konnten betroffene .de-Adressen zeitweise nicht aufgelöst werden, weil die Signaturen nicht zum veröffentlichten Schlüssel passten und die Antworten als ungültig verworfen wurden. Resolver ohne DNSSEC-Prüfung waren weniger betroffen. Mit dem Rücksetzen auf den vorherigen Schlüsselstand normalisierte sich die Auflösung wieder.
Was ist die zentrale Lehre für andere DNSSEC-Betreiber?
Wer mehrere Hardware-Sicherheitsmodule (HSMs) einsetzt, darf die Schlüssel nicht in jedem Gerät getrennt erzeugen. Das Schlüsselpaar muss an genau einer Stelle entstehen und danach in alle HSMs eingespielt werden. Andernfalls entstehen mehrere Schlüssel mit gleicher Kennnummer, von denen nur einer veröffentlicht ist - genau die Konstellation, die hier zwei Drittel der Signaturen ungültig machte.
Lag der Fehler an DNSSEC selbst?
Nein. DNSSEC hat korrekt funktioniert und die fehlerhaften Signaturen wie vorgesehen als ungültig markiert. Die Ursache war ein Fehler in der selbst entwickelten Signier-Software von DENIC, kombiniert mit einer Überwachung, deren Alarme nicht in eskalationsfähiger Form ankamen. Das Problem lag also im Betrieb und in der Test-Strategie, nicht im Protokoll.