DNS 06.05.2026 Aktualisiert: 08.05.2026

DENIC-Ausfall 2026: warum .de-Domains plötzlich verschwanden

Der DENIC-Ausfall vom 5. Mai 2026 war kein Hostingproblem, sondern DNSSEC in der .de-Zone. Was passiert ist und was Betreiber daraus lernen.

Stand: 08.05.2026, 18:00 Uhr CEST. Der Ausfall ist behoben. Dieser Artikel trennt zwischen dem, was wir am Abend beobachten konnten, und dem, was DENIC und Resolverbetreiber später technisch eingeordnet haben.

Kurzfassung

Worum es ging: Am Abend des 5. Mai 2026 waren viele .de-Domains zeitweise nicht oder nur sporadisch erreichbar.
Ursache: Nicht die einzelnen Websites, nicht einzelne Hoster und auch nicht die DNS-Root-Server. Das Problem lag in der DNSSEC-Signierung der .de-Zone bei DENIC.
Warum dig keine IP lieferte: Validierende Resolver mussten fehlerhaft signierte Antworten verwerfen und lieferten SERVFAIL. Für Nutzer sah das aus wie “Domain weg” oder “Website down”.
Warum manche Nutzer noch Zugriff hatten: DNS-Caches, “serve stale” und Resolver ohne aktive DNSSEC-Validierung konnten den Effekt abfedern.
Was besonders wichtig ist: Auch Domains ohne eigenes DNSSEC konnten betroffen sein, weil in der .de-Zone signierte Nachweise für Delegationen und fehlende DS-Records eine Rolle spielen.
Learning: Bei DNS-Störungen nicht nur Hosting, Domainstatus und Nameserver prüfen. Immer auch Resolververhalten, DNSSEC-Validierung und die Parent-Zone getrennt betrachten.

Wie es bei uns auffiel

Der Abend fing eigentlich harmlos an. Ich war mit einem ehemaligen Arbeitskollegen im Call. Wir hatten uns über alte Projekte unterhalten, ein bisschen in Erinnerungen gekramt, und irgendwann war eine seiner Domains nicht erreichbar.

Im Browser kam nichts Sinnvolles zurück. dig lieferte über den normalen Resolver keine IP. Mein erster Spruch war entsprechend trocken: “Hast du vergessen, die Domain zu verlängern?”

Das war natürlich nicht ernst gemeint. Aber genau deshalb blieb der Moment hängen. Eine nicht verlängerte Domain, ein kaputter Registrar-Status oder ein kaputter Nameserver sehen im ersten schnellen Blick manchmal ähnlich aus: keine Adresse, keine Website, Nutzer melden “geht nicht”.

Kurz danach kamen die ersten Kundenmeldungen. Nicht eine Website. Mehrere. Unterschiedliche Projekte, unterschiedliche Setups, gleiche Richtung: .de-Domains lösen nicht sauber auf.

Ab da war klar: Das ist kein einzelnes Kundenproblem.

Wir haben zuerst in die üblichen Richtungen geschaut. Domainstatus, authoritative Nameserver, Resolver, TTLs, Caches. Für einen Moment stand auch die Frage im Raum, ob es ein größeres Problem bei den DNS-Root-Servern oder in der Delegationskette gibt. DNSSEC hatten wir in den ersten Minuten nicht auf dem Schirm. Die naheliegende Vermutung war: Irgendwas an den .de-Zonen-Nameservern ist kaputt oder nicht erreichbar.

Das war knapp daneben. Die .de-Infrastruktur war nicht einfach “weg”. Sie lieferte Daten, aber validierende Resolver konnten diese Daten wegen fehlerhafter DNSSEC-Signaturen nicht mehr als vertrauenswürdig akzeptieren.

Das ist ein wichtiger Unterschied. Ein ausgefallener Nameserver antwortet nicht. Ein DNSSEC-Problem kann antworten, aber die Antwort ist kryptografisch unbrauchbar. Für den Nutzer endet beides oft in derselben Browsermeldung.

Timeline der Ereignisse

Die Zeiten sind in CEST angegeben. Bei internationalen Quellen ist UTC entsprechend umgerechnet.

Zeit	Ereignis
05.05.2026, ca. 21:30	Cloudflare beobachtet die ersten fehlerhaften DNSSEC-Signaturen für die `.de`-Zone. Validierende Resolver beginnen, betroffene Antworten mit `SERVFAIL` abzulehnen.
05.05.2026, ca. 21:43	Rekonstruktionen anhand historischer DNS-Daten zeigen fehlerhafte Signaturen im Umfeld des neuen DNSSEC-Schlüssels mit Key Tag `33834`.
05.05.2026, ab 21:57	DENIC nennt später diesen Zeitpunkt als Beginn der technischen Störung im DNS für `.de`.
05.05.2026, kurz vor 22:00	In der Praxis fallen erste Domains auf. Einzelne Checks wirken zunächst wie ein lokales Domain-, Resolver- oder Hostingproblem.
05.05.2026, ab ca. 22:00	Kundenmeldungen häufen sich. Der gemeinsame Nenner ist nicht der Hoster, sondern `.de` und die DNS-Auflösung über validierende Resolver.
05.05.2026, später Abend	DENIC bestätigt eine Störung des DNS-Service für `.de`-Domains. Zunächst stehen besonders DNSSEC-signierte Domains im Fokus.
06.05.2026, 00:08	DENIC startet die Verteilung einer korrigierten DNS-Zone.
06.05.2026, 00:17	Cloudflare setzt für `1.1.1.1` eine technische Überbrückung um, die praktisch wie ein Negative Trust Anchor für `.de` wirkt.
06.05.2026, 01:15	DENIC meldet den Betriebszustand vor dem Ausfall als vollständig wiederhergestellt.
06.05.2026, 14:30	DENIC ordnet den Vorfall einem regelmäßigen DNSSEC-Schlüsselwechsel zu und setzt künftige Wechsel vorsorglich aus.
08.05.2026	DENIC veröffentlicht eine technische Analyse: fehlerhafter Code im Signing-Prozess, nicht vollständig abgedeckte Tests, nicht korrekt verarbeitete Warnmeldungen und Auswirkungen auch auf Domains ohne eigenes DNSSEC.

Was DNSSEC hier eigentlich gemacht hat

DNSSEC ist keine Verschlüsselung. DNSSEC sorgt nicht dafür, dass niemand deine DNS-Abfragen lesen kann. Dafür wären andere Dinge wie DNS over TLS oder DNS over HTTPS zuständig.

DNSSEC beantwortet eine andere Frage: Ist diese DNS-Antwort echt und unverändert?

Dafür werden DNS-Daten kryptografisch signiert. Ein validierender Resolver prüft die Signaturkette von der Root-Zone über die Top-Level-Domain bis zur eigentlichen Domain. Wenn auf diesem Weg etwas nicht passt, darf der Resolver die Antwort nicht einfach trotzdem benutzen. Er muss sie verwerfen.

Genau das ist am 5. Mai passiert. Die Resolver haben nicht “kaputt” gearbeitet. Sie haben ihre Aufgabe erfüllt: fehlerhaft signierte Daten nicht als gültig ausliefern.

Das macht den Vorfall so unangenehm. Aus Sicht des Protokolls ist SERVFAIL in so einem Moment korrekt. Aus Sicht eines Kunden, dessen Shop oder Login gerade nicht erreichbar ist, hilft diese Korrektheit erst einmal wenig.

Warum auch Domains ohne eigenes DNSSEC betroffen sein konnten

Der erste Reflex ist: “Wenn meine Domain kein DNSSEC nutzt, kann mich ein DNSSEC-Ausfall doch nicht betreffen.”

Leider doch.

Die .de-Zone ist die Parent-Zone für alle .de-Domains. Sie liefert meistens keine finale IP-Adresse zurück, sondern Delegationsinformationen: Welche Nameserver sind für example.de zuständig? Gibt es einen DS-Record, also eine DNSSEC-Verknüpfung zur Child-Zone? Wenn es keinen DS-Record gibt, muss auch diese Abwesenheit bei DNSSEC sauber nachweisbar sein.

Dafür spielen NSEC3-Records eine Rolle. Sie beweisen kryptografisch, dass bestimmte Einträge nicht existieren. Wenn Signaturen über diese NSEC3-Records nicht validierbar sind, kann ein Resolver auch die Delegation einer eigentlich unsignierten Domain als “bogus” einstufen.

Das erklärt, warum der Ausfall breiter wirkte als “nur DNSSEC-signierte Domains sind betroffen”. Für Domainbetreiber ist das die bittere Stelle: Wenn die Parent-Zone auf TLD-Ebene ungültige DNSSEC-Daten verteilt, kannst du an deinem Webserver, deinem eigenen DNS-Provider oder deinem Zonefile oft nichts reparieren.

Wie man so etwas sauber eingrenzt

Bei solchen Störungen ist die wichtigste Frage: Wo bricht die Kette?

Ein paar einfache Checks helfen, die Richtung zu erkennen. Die Domains unten sind Platzhalter.

dig @1.1.1.1 example.de A +dnssec
dig @8.8.8.8 example.de A +dnssec
dig @9.9.9.9 example.de A +dnssec

Wenn mehrere validierende Resolver gleichzeitig SERVFAIL liefern, während andere Domains oder TLDs funktionieren, ist das ein starkes Signal.

Dann lohnt der Vergleich mit deaktivierter Validierungsanforderung:

dig @1.1.1.1 example.de A +cdflag

+cdflag setzt das “Checking Disabled”-Bit. Es ist kein Allheilmittel, weil Resolver unterschiedlich damit umgehen können. Wenn sich das Ergebnis dadurch aber deutlich verändert, liegt DNSSEC als Ursache näher.

Als Nächstes trennt man rekursive Resolver von autoritativen Antworten:

dig +trace example.de A
dig +trace example.de A +dnssec
dig @a.nic.de example.de NS +dnssec +multi
dig @a.nic.de de SOA +dnssec +multi

+trace validiert nicht wie ein Resolver, zeigt aber den Weg durch die Delegationskette. Mit +trace +dnssec sieht man zusätzlich DNSSEC-Daten wie DS-, DNSKEY- und RRSIG-Records im Trace. Direkte Abfragen an .de-Nameserver zeigen, ob die TLD-Ebene grundsätzlich antwortet. Wenn die TLD-Nameserver antworten, rekursive validierende Resolver aber SERVFAIL liefern, ist “Nameserver komplett down” wahrscheinlich nicht die richtige Erklärung.

Für DNSSEC selbst sind DS und DNSKEY die nächsten sinnvollen Prüfstellen:

dig @8.8.8.8 de DNSKEY +dnssec +multi
dig @8.8.8.8 example.de DS +dnssec +multi
dig @a.nic.de example.de DS +dnssec +multi

Der DNSKEY-Record zeigt die öffentlichen Schlüssel der Zone. Der DS-Record in der Parent-Zone verknüpft eine Child-Zone mit DNSSEC. Gibt es für eine Domain keinen DS-Record, muss auch diese Abwesenheit sauber signiert nachweisbar sein. Genau deshalb waren beim DENIC-Vorfall auch Domains betroffen, die selbst gar kein DNSSEC aktiviert hatten.

Bei DNSSEC-Problemen können Extended DNS Errors zusätzlich helfen. Manche Resolver liefern Hinweise wie DNSSEC Bogus. Cloudflare schrieb später, dass 1.1.1.1 während des Vorfalls zunächst nicht den hilfreichsten EDE-Code ausgab und das verbessern will. Auch daraus kann man etwas lernen: Fehlermeldungen von Resolvern sind wertvoll, aber nicht unfehlbar.

dig @1.1.1.1 example.de A +dnssec +comments | grep -i 'EDE\|Extended DNS'
dig @1.1.1.1 example.de A +dnssec +yaml | grep -i 'ede\|extended'

Die YAML-Ausgabe hängt von der installierten dig-Version ab. Der erste Befehl ist deshalb oft der robustere schnelle Check. Wenn der Resolver einen Extended DNS Error mitsendet, taucht er im Antwortkommentar als zusätzlicher Hinweis auf.

Warum der Verdacht “Root-Server” nahelag, aber nicht passte

Wenn plötzlich viele .de-Domains nicht mehr auflösen, denkt man schnell an eine Ebene weit oben im DNS-Baum. Root-Zone, TLD-Delegation, DENIC, große Resolver. Das ist als Arbeitshypothese nicht falsch.

Die DNS-Root-Server selbst waren hier aber nicht das Problem. Die Root-Zone delegiert .de an die zuständigen TLD-Nameserver. Wäre die Root-Ebene wirklich breit gestört, hätten wir sehr wahrscheinlich nicht nur .de gesehen.

Der Fehler lag eine Ebene darunter: in der signierten .de-Zone. Damit war die Auswirkung trotzdem groß genug. .de ist eine der größten Länderendungen weltweit, und ein Fehler auf TLD-Ebene trifft nicht einen einzelnen Kunden, sondern potenziell sehr viele Domains auf einmal.

Was DENIC später erklärte

DENIC ordnete den Vorfall einem routinemäßigen DNSSEC-Schlüsselwechsel zu. Im DNSSEC-Signaturprozess für .de kommen Standardsoftware, unter anderem Knot, Eigenentwicklungen und Hardware Security Modules zum Einsatz.

Nach DENICs Analyse wurde im April 2026 eine neue Generation dieses Systems in Betrieb genommen. Ein fehlerhaftes Stück Code in der Eigenentwicklung war durch die vorhandenen Tests und den kalten Parallelbetrieb nicht vollständig abgedeckt. Dadurch wurden nicht validierbare Signaturen erzeugt und verteilt.

DENIC schreibt außerdem, dass dauerhaft laufende Prüf- und Validierungswerkzeuge die Anomalien erkannt hatten, die Meldungen aber nicht korrekt verarbeitet wurden.

Das ist für Betreiber fast der wichtigste Satz im ganzen Vorfall. Monitoring, das ein Problem erkennt, aber nicht richtig eskaliert, ist im Ernstfall nur halb wirksam. Bei kritischer Infrastruktur reicht “wir hätten es technisch gesehen gesehen” nicht. Es muss auch beim richtigen Menschen oder beim richtigen Prozess landen.

Was Resolverbetreiber tun konnten

Für Betreiber rekursiver Resolver gibt es in solchen Fällen eine harte Abwägung.

Variante 1: DNSSEC weiter streng validieren. Dann bleiben manipulierte oder fehlerhaft signierte Daten blockiert. Bei einer kaputten TLD-Zone bedeutet das aber: viele legitime Domains liefern SERVFAIL.

Variante 2: DNSSEC-Validierung für die betroffene Zone vorübergehend aussetzen. Das ist technisch ein Negative Trust Anchor oder etwas funktional Ähnliches. Die Domains werden dann so behandelt, als wären sie nicht signiert. Das stellt Erreichbarkeit wieder her, senkt aber für diesen Zeitraum den DNSSEC-Schutz.

Cloudflare hat diese Abwägung öffentlich beschrieben und für .de temporär eine solche Überbrückung umgesetzt. DENIC erwähnt ebenfalls, dass einige große Resolverbetreiber die Validierung für .de vorübergehend ausgesetzt haben.

Das ist kein Schritt, den man leichtfertig macht. Aber wenn öffentlich klar ist, dass die Parent-Zone selbst fehlerhafte Signaturen verteilt, bringt ein hartes SERVFAIL für jede Anfrage keinen zusätzlichen Sicherheitsgewinn mehr. Es macht nur den Ausfall größer.

Was Betreiber daraus lernen sollten

Der Vorfall ist kein Argument gegen DNSSEC. Er ist ein Argument dafür, DNSSEC als echten Betriebsprozess zu behandeln.

Für Domain- und Plattformbetreiber bleiben aus meiner Sicht diese Punkte hängen:

DNS-Monitoring muss mehrere Resolver prüfen. Ein einzelner Resolver sagt zu wenig. Prüfe mindestens einen großen validierenden Resolver, den Resolver deines Providers und idealerweise eine zweite Region.
Nicht nur HTTP überwachen. Wenn nur der Webcheck alarmiert, fehlt der Kontext. Separates DNS-Monitoring mit RCODE, Antwortzeit und Resolver ist deutlich hilfreicher.
SERVFAIL ist ein anderes Signal als NXDOMAIN. NXDOMAIN heißt: Name existiert nicht. SERVFAIL heißt: Auflösung ist fehlgeschlagen. Das ist für die Ursachenanalyse ein großer Unterschied.
Parent-Zone und eigene Zone getrennt prüfen. Wenn die TLD-Ebene kaputt ist, helfen Änderungen am eigenen Zonefile nicht.
Statusseiten sollten nicht von derselben Fehlerdomäne abhängen. Eine Statusseite für DNS-Probleme unter einer betroffenen TLD ist im Ernstfall nur eingeschränkt hilfreich.
Runbooks brauchen DNSSEC. In vielen Betriebsdokus steht “Nameserver prüfen”, aber nicht “Validierung, DS, DNSKEY, RRSIG und NSEC3 prüfen”.
Kundensupport braucht eine technische Kurzdiagnose. Wenn klar ist, dass eine TLD-Störung läuft, sollte niemand stundenlang Webserver, Zertifikate oder Deployments jagen.

Gerade für Agenturen, Hoster und Betreiber vieler Kundendomains ist der letzte Punkt praktisch wichtig. Ein sauberer erster Befund spart Zeit und verhindert falsche Maßnahmen.

Was wir künftig anders prüfen

Ich nehme aus dem Abend vor allem mit, wie schnell man bei DNS erst einmal in die vertrauten Schubladen greift.

Domain abgelaufen? Registrarproblem? Nameserver down? Root-Server? Kaputter Resolver? Alles legitime Fragen. Nur war es diesmal die Signaturkette.

Für unsere eigenen Checks heißt das:

bei mehreren gleichzeitigen .de-Ausfällen sofort TLD- und DNSSEC-Ebene mitprüfen
SERVFAIL, NXDOMAIN, Timeout und leere Antwort sauber unterscheiden
+dnssec, +cdflag, +trace und direkte TLD-Abfragen griffbereit halten
Monitoring-Ergebnisse mit verschiedenen Resolvern vergleichen
bei Kundenmeldungen schneller kommunizieren, wenn die Ursache außerhalb des eigenen Einflussbereichs liegt

Wenn du viele Kundendomains betreibst, lohnt sich ein kleiner DNS- und Monitoring-Check, bevor der nächste Ausfall passiert. Nicht, weil man eine kaputte TLD-Zone selbst reparieren könnte. Sondern weil man schneller erkennt, dass man sie nicht selbst reparieren kann.

Update-Log

2026-05-06: Artikel angelegt. Erste Einordnung nach behobenem Ausfall: DNSSEC-Störung in der .de-Zone, Auswirkungen vor allem über validierende Resolver, kein einzelnes Hostingproblem.
2026-05-08: DENIC-Analyse eingearbeitet: Zusammenhang mit DNSSEC-Schlüsselwechsel, fehlerhafter Code im Signing-Prozess, nicht korrekt verarbeitete Warnmeldungen und Auswirkungen über NSEC3 auch auf Domains ohne eigenes DNSSEC.