Am Abend des 5. Mai 2026 verschwand ein Großteil des deutschen Internets – zumindest vorübergehend. Ab etwa 21:57 Uhr waren zahlreiche .de-Domains nicht mehr oder nur noch sporadisch erreichbar. Websites, E-Mail-Dienste und Apps wie die der Deutschen Bahn versagten plötzlich ihren Dienst. Die Ursache lag nicht bei einzelnen Anbietern, sondern tief im Fundament der deutschen Internet-Infrastruktur: bei der DENIC eG, der zentralen Registrierungsstelle für alle .de-Domains.
Was ist die DENIC – und warum ist sie so wichtig?
Die DENIC eG mit Sitz in Frankfurt am Main ist die einzige Institution, die die .de-Zone betreibt. Mit über 17 Millionen registrierten Domains ist die .de-Zone eine der größten Länderdomains weltweit. Wenn hier etwas schiefläuft, betrifft das potenziell Millionen von Nutzern und Unternehmen.
Das Domain Name System (DNS) funktioniert wie das Telefonbuch des Internets: Es übersetzt einen menschenlesbaren Domainnamen wie example.de in eine IP-Adresse, die Computer tatsächlich verwenden können. DNSSEC – die DNS Security Extensions – ist dabei eine Sicherheitserweiterung, die DNS-Antworten kryptografisch signiert, um Manipulationen wie DNS-Spoofing zu verhindern.
Was ist passiert?
Ursache war ein fehlgeschlagener DNSSEC-ZSK-Rollover (Zone Signing Key) in der .de-Zone. Konkret bedeutet das: Die Zonendaten wurden mit einem Schlüssel signiert, dessen öffentlicher Teil im DNSKEY-Set nicht oder nicht korrekt veröffentlicht war.
Einfach ausgedrückt: DENIC hat die .de-Zone mit einem Schlüssel unterschrieben, den sie vergessen hat, vorher öffentlich bekannt zu machen. Das Ergebnis war, dass jeder DNS-Resolver, der DNSSEC-Signaturen aktiv prüft, die Antwort als ungültig verwarf und mit einem „SERVFAIL“-Fehler reagierte.
Der Fehler deutet auf ein Problem beim Zone-Signing-Prozess auf Ebene der TLD-Registry hin – etwa nach einem Zonen-Update, einer Key-Transition oder einem Fehler in der Signing-Pipeline.
Warum waren auch nicht-DNSSEC-Domains betroffen?
Das ist die besonders tückische Seite dieses Vorfalls. Viele betroffene Domains hatten zum Zeitpunkt des Ausfalls gar kein aktives DNSSEC aktiviert und keine DS-Records bei DENIC registriert – und waren trotzdem nicht erreichbar.
Der Grund liegt in sogenannten NSEC3-Records: Diese dienen als signierter Nachweis, dass ein bestimmter Domainname in der Zone nicht existiert – also zum Beispiel, dass keine DNSSEC-Sicherung für eine bestimmte Domain vorliegt. Genau diese NSEC3-Records enthielten eine kryptografisch fehlerhafte RRSIG-Signatur. Da dieser fehlerhafte Verneinungsnachweis in der übergeordneten Zone lag, wurden alle Domains im betroffenen Hash-Bereich mitgerissen – unabhängig davon, ob sie selbst DNSSEC nutzten oder nicht.
Wer war betroffen – und wer nicht?
Betroffen waren vor allem Nutzer, deren DNS-Resolver DNSSEC-Signaturen aktiv validieren – also Dienste wie Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) und Quad9 (9.9.9.9). Viele deutsche ISP-Resolver verzichten hingegen auf diese Prüfung, weshalb ein Teil der Nutzer die betroffenen Domains weiterhin ungestört erreichen konnte.
Wer also seinen DNS auf bekannte öffentliche Resolver eingestellt hatte, war deutlich stärker betroffen als Nutzer, die den DNS ihres Internetanbieters nutzten. Außerdem half kurzzeitig noch der DNS-Cache: Solange eine Domain lokal zwischengespeichert war, funktionierte der Zugriff noch. Sobald jedoch eine frische DNS-Auflösung notwendig wurde, griff die Störung unmittelbar. Das erklärte den verwirrenden Eindruck, dass manche Seiten „manchmal funktionierten und manchmal nicht“.
Wie wurde das Problem behoben?
Um 00:08 Uhr am 6. Mai leitete DENIC die Verteilung der korrigierten DNS-Zone ein. Der Betriebszustand vor dem Ausfall konnte um 01:15 Uhr wieder vollständig hergestellt werden. DENIC führte dazu einen gezielten Signing-Run unter einem neuen Schlüssel durch, woraufhin sich die Resolver-Antworten nach Ablauf der TTL vollständig normalisierten.
Die Gesamtdauer der Störung betrug damit gut drei Stunden – für normale Anwender gefühlt eine halbe Ewigkeit.
Was lernen wir daraus?
Dieser Vorfall zeigt eindrucksvoll, wie fragil selbst gut gemeinte Sicherheitsmechanismen sein können. DNSSEC wurde eingeführt, um das DNS sicherer zu machen – und genau dieser Mechanismus hat hier dazu geführt, dass Millionen von Domains nicht mehr erreichbar waren. Das System hat dabei technisch gesehen korrekt funktioniert: Es hat fehlerhafte Signaturen erkannt und den Zugriff verweigert.
Das eigentliche Problem lag in einer prozeduralen Fehlerquelle: dem fehlgeschlagenen Schlüsselwechsel. Eine fehlerhafte Signatur in einer TLD-Zone ist besonders gravierend, weil sie sofort Millionen Domains aus der Auflösung wirft – ohne dass die betroffenen Domain-Betreiber irgendetwas dagegen tun könnten.
Eine ausführliche Post-Mortem-Analyse von DENIC steht zum Zeitpunkt dieses Artikels noch aus – sie dürfte jedoch spannende Einblicke in die Prozesse einer der wichtigsten deutschen Internet-Infrastrukturen liefern.
Der DENIC-Ausfall vom 5. Mai 2026 war ein Weckruf: Selbst die vertrauenswürdigste Infrastruktur ist nicht immun gegen menschliche Fehler. Für Betreiber von .de-Domains bedeutet das vor allem eines – Monitoring ist keine Option, sondern Pflicht. Wer frühzeitig über Ausfälle informiert wird, kann zumindest schnell reagieren und Nutzer informieren, auch wenn die eigentliche Ursache außerhalb des eigenen Einflussbereichs liegt.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
