DNS-Probleme mit .de-Domains: DENIC liefert erste Erklärung

Am 5. Mai um 21:43 knirschte es im deutschen Teil des Internets: Wer versuchte, Adressen mit der Endung .de aufzurufen, erhielt nur eine Fehlermeldung – zumindest, wenn der verwendete DNS-Server DNSSEC-Signaturen validierte. Erst nach 1 Uhr in der Nacht war das Problem vollständig behoben. Verantwortlich für die DNSSEC-Konfiguration der Zone .de ist die DENIC eG, die diese Domains verwaltet. Die hat jetzt Erklärungen für die Probleme geliefert.

Aus dem Blogbeitrag der DENIC geht hervor, dass die DNS-Server die Software Knot nutzen, ein Open-Source-Serverdienst, der von der tschechischen Domain-Verwaltungsorganisation CZ.NIC, Verwalterin der Domain .cz, gepflegt wird. Bei der DENIC läuft Knot zusammen mit „Eigenentwicklungen in Verbindung mit Hardware Security Modulen (HSMs)“. Im April 2026 habe man diese Infrastruktur auf die dritte Generation umgestellt.

Schlüsselkollision

Am 2. Mai begann dann der turnusmäßige Tausch des Zone-Signing-Keys. Veröffentlicht wurde ein neuer öffentlicher Schlüssel mit der ID 33834 – 3 Tage, bevor er zum ersten Mal zum Signieren benutzt wurde. Was da noch niemand ahnte: Im selbstentwickelten Teil des Codes steckte ein Fehler, der dazu führte, dass auf den Servern gleich drei Schlüsselpaare mit dem Tag 33834 erzeugt wurden, aber nur ein öffentlicher Schlüssel unter dieser Nummer veröffentlicht wurde. Als dieser Schlüssel erstmals benutzt wurde, um SOA-Einträge zu signieren, entstand das eigentümliche Fehlerbild, das man mit einem Werkzeug wie dnsviz.com nachverfolgen kann: Nur ein Teil der sechs DENIC-Nameserver nutzte jeweils den richtigen privaten Schlüssel, der zum öffentlichen Schlüssel passte, die anderen lieferten immer ungültige Signaturen aus. Der SOA-Eintrag wird häufig geändert, weil bei jeder Änderung an der Zone die Seriennummer in diesem Eintrag geändert wird. Das passt zum Hin-und-Her, das wir in einer ausführlichen Auswertung der vorliegenden Daten bereits beobachtet haben.

Die DENIC-Verantwortlichen halten fest, dass ein Codeabschnitt in der selbstgebauten Software „durch die Testszenarien nicht vollständig abgedeckt wurde und darum weder bei Testläufen, noch im ‚kalten‘ Parallelbetrieb vor der Inbetriebnahme als defekt erkannt wurde“ und betonen weiter, dass man gleich drei Prüfwerkzeuge auf die Zone anwende, die auch alle angeschlagen haben – „die Meldungen wurden allerdings nicht korrekt verarbeitet.“

Glücksspiel: Mit jeder Änderung an der Zone ändert sich die Seriennummer und eine neue Signatur ist fällig. Durch den Fehler nutzen die sechs Server einen von drei Schlüsseln, die unter der gleichen ID vorlagen. Nur einer war der zum öffentlichen Schlüssel passende.

Vollständige Klarheit liefert die Erklärung noch nicht. Der Code der Eigenentwicklungen ist nicht quelloffen, das verwendete Hardware Security Module wird nicht benannt und unter welchen Bedingungen die Schlüsselkollision ausschließlich im Produktivsystem und nicht in Testumgebungen auftrat, wird nicht erklärt. Immerhin verspricht man, mehr Informationen zu liefern, wenn die Untersuchung abgeschlossen ist.

Alle Domains betroffen

Im Blogbeitrag stellt die DENIC auch die Aussage aus der Nacht richtig, nach der nur solche Domains betroffen waren, bei denen DNSSEC aktiv war. Diese Behauptung deckte sich nicht mit Beobachtungen während des Ausfalls. Richtig ist, dass neben dem SOA-Eintrag auch NSEC3-Einträge betroffen waren. NSEC3 verhindert, dass ein Angreifer, der in den Verkehr eingreifen kann, DNSSEC einfach dadurch aushebeln kann, dass er die Antwort sendet „für diese Domain ist DNSSEC deaktiviert“. NSEC3 ist ein kryptografischer Beweis der Nichtexistenz. Ohne gültige NSEC3-Einträge scheiterte die DNSSEC-Prüfung für alle .de-Domains.

Fazit

Abgeschlossen ist der Fall noch nicht, wie die DENIC selbst schreibt. Die DENIC hat neben einer genauen Erklärung des Problems (bestenfalls inklusive Code) auch noch keine Liste an geplanten Maßnahmen veröffentlicht, wie ein solches Problem künftig erkannt werden könnte. Von solchen Erkenntnissen würden nicht nur Betreiber von DNSSEC-Infrastruktur für Domains, sondern auch andere TLD-Betreiber profitieren. Probleme mit Schlüsselkollisionen auf Ebene einer Toplevel-Domain sind nichts Neues: 2024 hatte der russische Betreiber der .ru-TLD einen Ausfall, Schuld war damals eine Schlüsselkollision.

(jam)