Deutschlands wichtigste Domain-Infrastruktur hat am Dienstagabend, dem 5. Mai 2026, einen seltenen und lehrreichen Ausfall erlebt. Das eigentliche News-Update kommt aber erst jetzt: DENIC hat am 8. Mai 2026 eine technische Analyse veröffentlicht und damit erstmals offengelegt, warum viele .de-Domains für rund drei Stunden nur noch SERVFAIL lieferten.
Wichtig ist dabei vor allem eines: Es ging nicht um einen Angriff auf einzelne Webseiten. Das Problem lag eine Ebene tiefer, direkt bei der Signierung der .de-Zone. Genau deshalb konnten selbst technisch gesunde Websites plötzlich für einen Teil der Nutzer unsichtbar werden.
Was jetzt offiziell feststeht
- Laut Cloudflare wurden fehlerhafte DNSSEC-Signaturen für die
.de-Zone am 5. Mai 2026 gegen 19:30 UTC veröffentlicht, also gegen 21:30 Uhr CEST. - DENIC datiert die spürbaren Einschränkungen offiziell auf 21:57 Uhr CEST.
- Um 00:08 Uhr CEST am 6. Mai 2026 begann die Verteilung der korrigierten Zone.
- Um 01:15 Uhr CEST war der Zustand vor dem Ausfall laut DENIC wieder vollständig hergestellt.
Die leichte Zeitdifferenz zwischen Cloudflare und DENIC ist plausibel: Cloudflare beschreibt, wann falsche Signaturen im Resolver-Verkehr sichtbar wurden. DENIC benennt den Zeitpunkt, ab dem die Störung operativ bemerkbar war.
Die Ursache laut DENIC
DENIC spricht inzwischen nicht mehr nur allgemein von einem "regulären Schlüsselwechsel", sondern nennt einen konkreten technischen Fehler. Im April 2026 hatte die Genossenschaft die dritte Generation ihres DNSSEC-Signatursystems in Betrieb genommen. In einer Eigenentwicklung, die zusammen mit Standardsoftware und HSMs arbeitet, landete dabei fehlerhafter Code im Produktivsystem.
Die Folge war gravierend: Für denselben Key Tag 33834 wurden laut DENIC nicht ein, sondern drei verschiedene Schlüsselpaare erzeugt. Im veröffentlichten DNSKEY-Record lag aber nur der öffentliche Schlüssel eines einzigen Paars. Damit war nur ein Teil der erzeugten Signaturen überhaupt prüfbar.
Besonders kritisch wurde das beim SOA-Record der .de-Zone. Weil dieser bei jeder Zonenänderung mit neuer Seriennummer neu signiert werden muss, war er im Verlauf mal gültig und mal ungültig. Genau diese Inkonsistenz ist Gift für validierende Resolver.
Warum selbst nicht signierte Domains betroffen waren
Das ist der Teil, den viele Betreiber falsch einschätzen würden. Man könnte vermuten, dass nur explizit mit DNSSEC signierte Second-Level-Domains betroffen waren. Laut DENIC war das aber nicht so.
Der Grund liegt bei den für Delegationen wichtigen NSEC3-Records. Resolver brauchen sie auch dann, wenn eine untergeordnete Domain selbst kein DNSSEC nutzt, etwa um die Abwesenheit eines DS-Records sauber zu belegen. Wenn diese Nachweise nicht mehr valide signiert sind, wird die Antwort als bogus eingestuft. Das Resultat ist dann kein langsamer Zugriff und kein HTTP-Fehler, sondern bereits vorher ein DNS-Fehler.
Kurz gesagt: Der Ausfall saß auf TLD-Ebene. Deshalb war die Reichweite viel größer als bei einer kaputten Einzel-Domain.
Warum nicht alle Nutzer dasselbe gesehen haben
DENIC und Cloudflare beschreiben denselben Effekt aus zwei Richtungen: Betroffen waren vor allem Nutzer mit validierenden Resolvern. Wer etwa auf besonders strikte öffentliche Resolver oder Unternehmens-DNS setzte, bekam fehlerhafte Antworten konsequent verworfen. Andere Nutzer bemerkten teilweise nichts, weil ihre Resolver DNSSEC für .de vorübergehend nicht streng validierten oder zwischengespeicherte Daten nutzten.
Cloudflare betont zusätzlich, dass .de zu den weltweit am stärksten abgefragten TLDs gehört. Ein Fehler an dieser Stelle kann also nicht nur ein paar Nischenseiten treffen, sondern potenziell Millionen Domains unerreichbar machen.
Der Vorfall war deshalb kein klassischer Website-Ausfall, sondern ein Infrastrukturproblem im Vertrauensanker für die gesamte
.de-Zone.
Was Betreiber daraus konkret lernen sollten
Für Admins und Unternehmen ist der Fall mehr als ein peinlicher Zwischenfall bei einer Registry. Er zeigt sehr konkret, wo viele Monitoring-Setups blind sind.
- Ein grüner HTTP-Check auf dem Origin reicht nicht, wenn DNS-Auflösung extern scheitert.
- DNS-Monitoring sollte immer auch über mindestens einen validierenden externen Resolver geprüft werden.
- DNSSEC abzuschalten ist keine saubere Lehre aus dem Vorfall. Die richtige Lehre ist bessere Überwachung, schnellere Alarmverarbeitung und klarere Fallback-Prozesse.
DENIC selbst schreibt, dass vorhandene Prüf- und Validierungswerkzeuge die Anomalie zwar erkannt hätten, die Meldungen aber nicht korrekt verarbeitet wurden. Das ist vielleicht der wichtigste Satz der gesamten Analyse: Nicht nur der Signaturfehler selbst war das Problem, sondern auch das Versagen der operativen Reaktion auf erkannte Warnungen.
Fazit
Am 8. Mai 2026 wurde aus einer nächtlichen .de-Störung ein deutlich größeres Thema: eine offizielle Root-Cause-Analyse für einen Ausfall in zentraler deutscher Internet-Infrastruktur. Nach jetzigem Stand war es kein Angriff, sondern ein hausgemachter Softwarefehler im DNSSEC-Prozess, verstärkt durch unzureichend abgefangene Warnsignale.
Für Leser heißt das vor allem: Wenn eine Website plötzlich "weg" ist, muss weder Ihr Anschluss noch der Webserver selbst kaputt sein. Manchmal bricht das Problem weiter oben, in der unsichtbaren Kette des DNS-Vertrauens. Genau das ist am 5. Mai 2026 bei .de passiert.