DNSSEC-Ausfall bei .de: Was schiefging und wie man es vermeidet

Stellt euch vor, ihr wechselt um zwei Uhr nachts eure Live-Systeme – alles getestet, alles perfekt. Und dann kracht es. Genau das ereignete sich am 5. Mai 2026 beim .de-Registry. Drei Stunden lang waren Tausende .de-Websites offline. Nicht durch fehlende Domains, sondern weil die eigene Sicherheitsmaßnahme sie lahmlegte.

Der Auslöser: Tech-Fehler plus Prozessloch

Das .de-Team hatte monatelang an einem neuen DNSSEC-Signiersystem gearbeitet. Drittgeneration, gründlich geprüft und auditiert. Sah unzerstörbar aus.

Doch dann passierte Folgendes: Das System spuckte drei verschiedene Key-Paare aus statt einem und veröffentlichte nur eines. Resolver suchten nach dem falschen Public Key, und die Signaturen passten nicht.

Technisch spannend: Alle drei Keys bekamen denselben Key Tag (33834) – quasi den Fingerabdruck. Zwei Drittel der Resolver warfen bei der Prüfung hin, weil Private und Public Key nicht matchten. Jede Zone-Änderung signierte neu den SOA-Record. Manche Updates gingen durch, andere nicht. Chaos pur.

Warum versagten die Alarme?

Bitterer Punkt: Die Erkennung funktionierte einwandfrei. Drei unabhängige Tools meldeten die fehlerhaften Signaturen sofort.

Aber: Keiner reagierte. Die Alerts verschwanden im Monitoring-Trubel. Das war kein Tech-Problem, sondern ein reines Prozessversagen. Jede Firma mit kritischer Infra kennt das Risiko.

Merkt euch: Gute Überwachung braucht klare Eskalationswege und Verantwortliche. Sonst ist es nur Lärm.

Der Domino-Effekt: Auch ohne DNSSEC betroffen

Besonders fies: DNSSEC schützt nicht nur signierte Domains. Es beweist per NSEC3 auch, dass unsigned Domains kein Signature haben.

Fehlerhafte NSEC3-Signaturen machten die gesamte .de-Delegation für Resolver ungültig – inklusive Domains ohne DNSSEC. Eure beispiel.de ohne Security war plötzlich tot, weil der Nameserver-Delegation "bogus" galt.

Viele DNS-Betreiber unterschätzen das erst bei so einem Knall.

Die Notlösung von Profis

Positiv: Große Resolver-Operatoren schalteten DNSSEC für .de vorübergehend aus. Traffic floss wieder. Das Registry dankte öffentlich.

Das zeigt: Internet-Infra funktioniert. Erfahrene Operatoren entscheiden schnell und richtig, um Schaden zu begrenzen.

Lektionen für Devs und Ops

Dieser Fall lehrt uns viel:

1. Tests haben Lücken. Auditiertes Code scheitert live. Der Multi-Key-Bug kam durch alle Pre-Prod-Checks.

2. Alerts ohne Action taugen nichts. Drei Systeme piepsten perfekt – ohne Follow-up nutzlos.

3. Versteht eure Abhängigkeiten. TLD-Änderungen wirken sich auf Subdomains aus, auch unsigned.

4. Parallel-Run reicht nicht. .de testete nebenbei live – doch Prod-Verhalten unterschied sich.

5. Schreibt Incident-Pläne. Resolver wussten, was zu tun ist. Habt ihr das?

Ausblick

Das .de-Team verspricht gründliche Analyse. Erwartet strengere Tests für DNSSEC, bessere Alert-Prozesse und Zone-Verbesserungen.

Für NameOcean-Nutzer oder eigene DNS-Setups gilt:

• Wählt Provider mit starkem Monitoring und Response.
• Kennt DNSSEC-Folgen vor dem Einschalten.
• Pflegt Kontakte zu DNS-Experten.
• Baut direkte On-Call-Verbindungen in die Überwachung ein.

Am Ende: Nach drei Stunden war alles wieder da. Infra hielt stand. Und wir alle sind schlauer.

Das wiegt den Ausfall auf.

Hattet ihr schon DNS-Pannen? Was habt ihr daraus gelernt? Teilt eure Erfahrungen – zusammen machen wir Systeme robuster.