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.
Was ist neu
DENIC 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 zu verteilen, generierte die Eigenentwicklung "gleich drei verschiedene Schlüsselpaare", eines pro HSM. Alle drei trugen denselben Key Tag 33834, und das DNSKEY-Set veröffentlichte nur einen der drei Public Keys. Damit ließen sich rund zwei Drittel der RRSIGs, 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 vor der Inbetriebnahme, der die Fehlerklasse nicht aufgedeckt hat.
Was sich praktisch ändert
Die im Hauptartikel beschriebene DNSSEC-Logik bleibt unverändert: validierende Resolver mussten die Antworten als bogus verwerfen, der Rollback 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.
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 bei Mehrfachsigner-Setups auch die Anzahl unterscheidbarer Signaturen je Key Tag innerhalb des TTL-Fensters mitzählen. Weicht sie von der erwarteten Konfiguration ab, ist das ein Frühindikator.
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.