DENIC-Störung: Warum tausende .de-Domains in der Nacht plötzlich verschwanden
In der Nacht vom 5. auf den 6. Mai 2026 waren zahlreiche .de-Domains für Teile der Nutzer weltweit nicht erreichbar – darunter prominente Adressen wie bahn.de und spiegel.de. Die Ursache war kein Cyberangriff, kein Konfigurationsfehler einzelner Betreiber. Es war ein Signaturfehler tief in der DNS-Infrastruktur Deutschlands.
Was passiert ist
Am Abend des 5. Mai 2026 – im Rahmen eines angekündigten Wartungsfensters – traten bei der DENIC, der deutschen Registrierungsstelle für alle .de-Domains, massive Probleme auf. Zwischen 21:40 und 23:30 Uhr MESZ waren Teile aller deutschen .de-Domains weltweit nicht erreichbar. Nutzer sahen stattdessen Fehlermeldungen wie „DNS-Adresse des Servers nicht gefunden" – obwohl die betroffenen Domains technisch vollständig korrekt konfiguriert waren.
DENIC selbst bestätigte die Störung noch in der Nacht und meldete gegen 23:30 Uhr deren Behebung.
Die technische Ursache: Ein Signaturfehler in der .de-Zone
Wer nur die Fehlermeldung im Browser sah, konnte den Eindruck bekommen, das Problem liege bei der eigenen Domain oder beim Hoster. Das stimmte nicht.
Der eigentliche Fehler lag bei DENIC selbst: Im Zuge der Wartungsarbeiten wurden DNSSEC-Signaturen in der .de-Zone fehlerhaft ausgeliefert. Konkret betraf es sogenannte NSEC3-Records – Einträge, die kryptografisch belegen, dass eine bestimmte Domain keinen DS-Record (Delegation Signer) besitzt. Genau diese Verneinungsaussage war mit einer fehlerhaften Signatur (RRSIG, Keytag 33834) versehen.
Das Ergebnis: DNS-Resolver, die DNSSEC-Signaturen aktiv prüfen – darunter Google DNS (8.8.8.8), Cloudflare (1.1.1.1) und Quad9 (9.9.9.9) – stuften die Vertrauenskette als ungültig ein und verweigerten die Auflösung. Antwort: SERVFAIL.
Wer seinen DNS-Resolver auf ISP-Standard betrieb, war in vielen Fällen gar nicht betroffen – weil viele deutsche Internetanbieter DNSSEC-Signaturen nicht strikt validieren.
Was DNSSEC damit zu tun hat
DNSSEC ist ein Sicherheitsmechanismus, der DNS-Antworten kryptografisch signiert. Ziel ist es, zu verhindern, dass Angreifer DNS-Anfragen manipulieren und Nutzer auf gefälschte Seiten umleiten.
Damit das funktioniert, gibt es eine mehrstufige Vertrauenskette: von der Root-Zone über die TLD-Registry (hier: DENIC für .de) bis zum einzelnen Nameserver. Wenn irgendwo in dieser Kette eine Signatur fehlerhaft ist, verweigern validierende Resolver die Auflösung – zum Schutz des Nutzers.
Das klingt zunächst wie ein Sicherheitsmerkmal, das funktioniert. Und technisch ist es das auch. Nur: In diesem Fall war nicht die Domain kompromittiert, sondern die Signaturinfrastruktur der Registry selbst fehlerhaft. Die Schutzfunktion wurde zum Ausfallgrund.
Wer betroffen war – und wer nicht
Das Störungsbild war ungewöhnlich selektiv: Nutzer mit modernen, sicherheitsbewussten DNS-Einstellungen waren betroffen. Nutzer mit Standard-ISP-Resolvern meist nicht.
Das erklärt, warum der Vorfall trotz prominenter betroffener Domains zunächst kaum öffentliche Aufmerksamkeit erzeugte. Der Ausfall war real – aber er war unsichtbar für die Mehrheit der Nutzer.
Für Unternehmen bedeutet das: DNS-Ausfälle dieser Art laufen geräuschlos ab. Kein Massenalert, kein offensichtliches Warnsignal – nur ein Teil der Nutzer kann die Seite nicht erreichen, ein anderer Teil problemlos.
Was Domainbetreiber in diesem Fall tun konnten – und was nicht
Wichtig für alle Betroffenen: Es gab in diesem Fall keine sinnvolle Handlungsoption auf Betreiberseite. Der Fehler lag ausschließlich in der Signaturinfrastruktur der DENIC. Weder die eigene DNS-Konfiguration noch der Registrar-Eintrag waren das Problem.
Der einzig zielführende Weg war die Meldung an den Registrar mit der Bitte um Weiterleitung an DENIC – verbunden mit einem dokumentierten Fehlerbefund (betroffene Resolver, Zeitstempel, dig-Ausgaben).
Nach Korrektur durch DENIC normalisierten sich die Resolver-Antworten automatisch nach Ablauf der gespeicherten Cache-Zeiten (TTL: 7.200 Sekunden – also rund zwei Stunden).
Dieser Vorfall zeigt
Dieser Ausfall war kein Angriff. Er war kein Betreiberfehler. Er war ein Infrastrukturversagen an einer Stelle, auf die Domainbetreiber keinen Einfluss haben – und dennoch unmittelbar spürten.
Das ist die eigentliche Lektion: DNS ist keine passive, zuverlässige Infrastruktur im Hintergrund. Es ist ein aktives Sicherheitssystem mit komplexen Abhängigkeiten – und Fehler können jederzeit aus einer übergeordneten Ebene kommen, ohne Vorwarnung.
Für Unternehmen mit öffentlich erreichbaren Diensten bedeutet das konkret:
- DNS-Monitoring gehört in jedes Availability-Monitoring – und zwar gegen mehrere validierende Resolver, nicht nur gegen den eigenen
- SERVFAIL ist kein technischer Randfall – er kann jede korrekt konfigurierte Domain treffen, wenn die übergeordnete Zone ein Problem hat
- Incident-Response braucht einen DNS-Pfad – inkl. Eskalationsweg zum Registrar und Dokumentationsstandard für den Fehlerfall
- DNSSEC-Validierung ist ein Sicherheitsgewinn – aber nur, wenn die Signaturinfrastruktur der Registry zuverlässig betrieben wird
Haben Sie den Ausfall bemerkt – oder hätten Sie ihn bemerkt?
Wer in der Nacht des 5. Mai nicht aktiv auf seine Domain-Erreichbarkeit geprüft hat, hat den Vorfall möglicherweise erst im Nachhinein erfahren – oder gar nicht.
DNS-Monitoring ist kein Aufwand, der sich nur bei großen Incidents rechnet. Es ist die Voraussetzung dafür, überhaupt zu wissen, wenn ein Teil Ihrer Nutzer Ihre Dienste nicht erreichen kann.
enthus unterstützt Sie beim Aufbau eines belastbaren Availability- und DNS-Monitorings – von der technischen Einrichtung bis zur Integration in bestehende IT-Betriebsprozesse.
Sprechen Sie uns an – wir helfen bei der Einschätzung.
Schreiben Sie uns
Sie haben Fragen zu diesem Blog-Beitrag oder benötigen einen Expertenrat zu einem anderen Thema,
dann schreiben Sie uns gerne und wir melden uns bei Ihnen zurück.