Version 1.0: Mai 2026
DNSSEC Vorfall Analyse basierend auf eigener Live Diagnose während des Ausfalls am 5. Mai 2026 zwischen 21:40 und 23:30 Uhr MESZ. Verifiziert über DNS Anfragen gegen Cloudflare, Google und Quad9 sowie über die DoH Schnittstellen von Google und Cloudflare.
Nächste geplante Aktualisierung: August 2026.
Am Montagabend, 5. Mai 2026, war zwischen 21:40 und 23:30 Uhr MESZ ein Teil aller deutschen .de-Domains weltweit nicht erreichbar. Endnutzer sahen im Browser die Fehlermeldung DNS_PROBE_FINISHED_NXDOMAIN, also „Domain existiert nicht“, obwohl die Server völlig in Ordnung waren. Die wichtigsten Fakten zum Vorfall im Überblick:
Wer eine .de-Domain betreibt, sollte aus dem Vorfall mitnehmen: DNS Monitoring mit DNSSEC Awareness ist 2026 keine optionale Ergänzung mehr, sondern operative Pflicht. Klassische Uptime Checks hätten den Vorfall nicht erkannt, weil die Webserver technisch erreichbar waren. Nur die DNS Auflösung scheiterte.
Das Symptom war so simpel wie irritierend. Wer eine betroffene .de-Domain im Browser aufrief, sah keinen Server Fehler, kein Timeout, keine 500er Meldung, sondern die für viele Nutzer verwirrende Aussage „Diese Seite ist nicht erreichbar. Die DNS-Adresse des Servers wurde nicht gefunden.“ mit dem technischen Code DNS_PROBE_FINISHED_NXDOMAIN.
NXDOMAIN bedeutet wörtlich übersetzt: „Diese Domain existiert nicht.“ Für einen Endnutzer ist das eine seltsame Aussage über eine Seite, die er gestern noch problemlos besucht hat. Die typische erste Reaktion war entsprechend: Browser Cache leeren, Router neu starten, beim Hoster anrufen. All das half nichts. Auch ein Wechsel vom WLAN auf mobile Daten brachte keine Besserung, weil sowohl der heimische Internet Provider als auch der Mobilfunk Carrier dieselbe technische Antwort vom System bekamen.
Besonders verwirrend: Manche .de-Domains funktionierten weiterhin einwandfrei, andere waren komplett unerreichbar. Heise.de oder tagesschau.de liefen problemlos, während spiegel.de, bild.de und onlinewachsen.de zeitgleich verschwunden waren. Diese scheinbare Zufälligkeit machte die Fehlersuche für Endnutzer praktisch unmöglich.
Bei onlinewachsen war ich gegen 21:50 Uhr selbst von dem Problem betroffen. Unsere eigene Agenturwebsite onlinewachsen.de war nicht erreichbar, dazu drei Kundenprojekte. Die strukturierte Diagnose, die ich in den folgenden zweieinhalb Stunden durchgeführt habe, lief in fünf klar abgegrenzten Schritten ab.
Mehrere Geräte, mehrere Netzwerke. Wenn das Problem auf Desktop und Smartphone und in WLAN und Mobilfunk gleichzeitig auftritt, liegt es nicht an einem einzelnen Endgerät und nicht am eigenen Router. Diese Ausschluss Diagnose dauert keine zwei Minuten und eliminiert die häufigsten falschen Annahmen sofort.
Die betroffenen Domains lagen bei vier völlig unterschiedlichen Hostern: Hostinger, IONOS, Alfahosting und All-Inkl. Vier verschiedene Hoster mit gleichzeitigem Ausfall sind extrem unwahrscheinlich, also liegt die Ursache nicht beim Hosting. Diese Erkenntnis verschiebt den Fokus von Server Konfiguration auf Netzwerk Infrastruktur.
Standard Anfragen an Cloudflare (1.1.1.1), Google (8.8.8.8) und Quad9 (9.9.9.9) lieferten alle dieselbe Antwort: SERVFAIL für die betroffenen Domains, NOERROR für andere wie google.de. Wenn drei voneinander unabhängige Resolver weltweit denselben Fehler zeigen, ist es kein lokales Problem, sondern ein Problem auf Resolver oder TLD Ebene.
Die entscheidende Diagnose Erkenntnis kam, als ich dieselben Anfragen mit deaktivierter DNSSEC Validierung wiederholte (sogenanntes Checking Disabled Flag). Sofort kamen die korrekten IP Adressen zurück. Die Daten waren also vorhanden, nur die kryptografische Validierung schlug fehl. Damit war die Ursache eingegrenzt.
Die DNS over HTTPS Schnittstelle von Google liefert bei Validierungsfehlern einen erklärenden Kommentar mit. Für die betroffenen Domains kam wörtlich zurück: „DNSSEC validation failure. Check http://dnsviz.net/d/[domain]/dnssec/ and http://dnssec-debugger.verisignlabs.com/[domain] for errors.“ Damit war die Diagnose eindeutig.
Die exakte Root Cause wurde später am Abend in einem Hacker News Thread öffentlich von einem DNSSEC Spezialisten dokumentiert: „RRSIG with malformed signature found for a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834).“
Um zu verstehen, was an diesem Abend wirklich schiefgegangen ist, lohnt sich ein kurzer Ausflug in das, was DNSSEC eigentlich ist. Wer das schon kennt, kann zum nächsten Abschnitt springen.
Das normale Domain Name System (DNS) übersetzt Domainnamen wie onlinewachsen.de in IP Adressen. Das Problem dabei: Die Antworten sind ungesichert. Theoretisch könnte jeder, der sich in den Antwortpfad einklinkt, eine falsche IP Adresse zurückliefern und Nutzer auf eine manipulierte Webseite umleiten. Das nennt sich DNS Spoofing oder Cache Poisoning, und es ist über die Jahre tatsächlich vorgekommen.
DNSSEC steht für Domain Name System Security Extensions und wurde im März 2005 in den RFCs 4033, 4034 und 4035 standardisiert. Die Grundidee: Jede DNS Antwort wird kryptografisch signiert, so wie man früher Briefe mit einem Wachssiegel versah. Empfänger können prüfen, ob das Siegel echt ist, und Manipulationen so erkennen.
Die Vertrauenskette funktioniert hierarchisch:
Wenn ein Resolver eine Antwort prüft, geht er diese Kette von oben nach unten durch und stellt sicher, dass jedes Siegel korrekt ist. Schlägt nur ein Glied fehl, wird die gesamte Antwort verworfen. Statt potenziell manipulierter Daten gibt der Resolver dann SERVFAIL zurück, was im Browser als NXDOMAIN dargestellt wird.
DNSSEC arbeitet pro Zone mit zwei Schlüsseln:
DENIC tauscht diesen ZSK alle fünf Wochen automatisch aus, beschrieben in der DENIC DNSSEC FAQ. Dieser regelmäßige Tausch des ZSK heißt Rollover und folgt dem standardisierten Pre Publish Verfahren. Genau dort ist am 5. Mai 2026 der Fehler passiert.
Eine Eigenheit von DNSSEC ist, dass nicht nur existierende Daten signiert werden, sondern auch die Aussage „diese Domain existiert nicht“. Sonst könnte ein Angreifer die Antwort auf „gibt es bank.de?“ einfach mit „nein, gibt es nicht“ verfälschen.
Das geschieht über sogenannte NSEC3 Records. Sie enthalten kryptografische Hashes der existierenden Domains in einer Zone und beweisen damit, dass eine angefragte Domain in keinem dieser Hashes vorkommt. Auch diese NSEC3 Records werden mit einer kryptografischen Signatur (einem RRSIG Record) versehen. Genau ein solches NSEC3 RRSIG Paar war am 5. Mai 2026 fehlerhaft.
Bei DENIC war zum Vorfallszeitpunkt der reguläre ZSK Rollover im Pre Publish Verfahren aktiv. Das bedeutet: Der neue ZSK wird zunächst nur in der Zone veröffentlicht, ohne dass damit signiert wird. Erst nach Ablauf einer Wartezeit, in der die Resolver weltweit den neuen Schlüssel in ihren Caches speichern können, wird auf das Signieren mit dem neuen Schlüssel umgestellt.
Bei diesem Umstellprozess am Abend des 5. Mai 2026 ist eine fehlerhafte RRSIG Signatur in die produktive Zone gelangt. Konkret betroffen war der NSEC3 Record mit dem Hash a0d5d1p51kijsevll74k523htmq406bk.de. Die zugehörige Signatur über diesen Record sollte mit dem ZSK Keytag 33834 erstellt worden sein, validierte aber nicht gegen genau diesen Schlüssel.
Die Folge war so radikal wie unausweichlich: Jeder Resolver, der DNSSEC Validierung aktiviert hat (und das sind fast alle modernen Public Resolver sowie ein wachsender Anteil deutscher ISP Resolver), prüfte die Antwort, bemerkte die ungültige Signatur und verwarf die Antwort vollständig. Die Browser Endmeldung NXDOMAIN war eigentlich eine SERVFAIL Antwort des Resolvers, die der Browser nutzerfreundlich als „nicht gefunden“ interpretierte.
Die DENIC betreibt 16 Servicestandorte für die .de-Zone in Anycast Topologie. Berichten aus dem Hacker News Thread zufolge servierten einige dieser Standorte zeitweise noch die vorherigen, gültigen Signaturen aus ihrem internen Cache, andere die neuen, fehlerhaften. Das erklärt, warum manche Endnutzer den Vorfall stärker erlebten als andere: Die Frage, welcher der Anycast Knoten gerade antwortete, entschied über Erreichbarkeit.
Gegen 23:30 Uhr MESZ war der fehlerhafte Stand korrigiert und die Zone neu signiert. Damit war der Vorfall im Kern beendet, allerdings nicht für alle Endnutzer sofort spürbar.
Eine der häufigsten Beobachtungen während des Vorfalls war die scheinbare Willkür: Warum funktionierte heise.de, aber spiegel.de nicht? Warum amazon.de zeitweise ja, zeitweise nein? Die Antwort liegt in einer Kombination aus drei technischen Mechanismen, die zusammenwirken.
Wenn ein Resolver einmal eine gültige DNS Antwort empfangen hat, speichert er sie für eine bestimmte Zeit (TTL = Time To Live) im Cache. Häufig besuchte Domains wie heise.de oder telekom.de waren in den Caches der großen Resolver durchgehend frisch zwischengespeichert, weil ständig irgendjemand auf der Welt diese Adressen abruft. Die Resolver mussten also gar keine neue Anfrage an die DENIC Server stellen und bekamen folglich auch keine fehlerhafte Signatur.
Die 16 .de-Servicestandorte der DENIC arbeiten in einer Anycast Architektur. Die Anfrage eines Resolvers landet auf dem Server, der ihm geografisch und netzwerktechnisch am nächsten ist. Wenn fünf der 16 Standorte den fehlerhaften Stand schneller empfangen haben als die anderen elf, bekommen Anfrager je nach geografischer Lage entweder die kaputte oder die noch gute Antwort.
Domains, die selten abgerufen werden, lagen nicht in den Resolver Caches. Jede neue Anfrage musste also tatsächlich beim TLD Server nachfragen und bekam dort die fehlerhafte Signatur. Das traf vor allem kleinere Geschäftswebsites und Agenturprojekte, weniger die großen Massenseiten.
Diese drei Effekte zusammen erklären, warum kleinere Unternehmen und Agenturen den Vorfall deutlich heftiger erlebten als die durchschnittliche Tagesschau Leserin. Ironischerweise war damit die Gruppe am stärksten betroffen, die am wenigsten technische Diagnose Möglichkeiten hat.
Stichprobenartige Tests während des Vorfalls über das Cloudflare DoH Interface zeigten ein klares Muster. Folgende prominente .de-Domains lieferten zeitweise SERVFAIL bei standardgemäßer Auflösung:
Funktioniert haben durchgehend google.de, amazon.de, heise.de, ionos.de, telekom.de, zalando.de, ebay.de, freenet.de und tagesschau.de.
Die Frage, ob eine Domain betroffen war oder nicht, hatte nichts mit ihrer Größe oder Wichtigkeit zu tun. Sie hing einzig und allein davon ab, ob die zuständigen Resolver eine frische, noch gültige Antwort im Cache hatten und welcher Anycast Knoten ihre Anfrage erreichte. Bei onlinewachsen waren alle .de-Domains unserer Kunden, die wir im Test geprüft haben, betroffen. Domains auf .com und .info liefen durchgehend problemlos, weil sie über andere TLDs aufgelöst werden.
Auch der E-Mail Verkehr war indirekt betroffen. Wenn ein sendender Mailserver versucht, den MX Record einer empfangenden .de-Domain aufzulösen, scheitert das im Vorfall ebenso wie die Webseiten Auflösung. E-Mails an Adressen mit betroffenen Domains konnten in dieser Phase nicht zugestellt werden und liefen entweder in temporäre Warteschleifen oder erhielten einen Bounce.
Eine Beobachtung, die viele Betroffene während des Vorfalls verunsichert hat: Es gab praktisch keine Berichterstattung in den großen deutschen Tech Medien. Heise, Golem und t3n schwiegen zur Vorfallszeit komplett. Auch DENIC selbst meldete auf der eigenen Status Seite durchgehend „All Systems Operational“. Das hat mehrere Gründe.
Wer betroffen ist, kann oft nichts schreiben. Wenn die eigene Redaktions Website oder das eigene Publishing System auf einer .de-Domain läuft, geht in dem Moment auch das Veröffentlichen nicht. Die Sysadmins, die den Vorfall am schnellsten verstanden haben, waren mit der Fehlersuche bei sich selbst beschäftigt.
Die großen Tech Seiten waren zufällig nicht betroffen. Heise.de, golem.de und tagesschau.de funktionierten während des Vorfalls. Was nicht stört, wird nicht berichtet. Ein Redakteur dort hatte schlicht keinen Anlass, das Thema aufzugreifen.
DNSSEC Fehler sind unsichtbar. Der Endnutzer sieht nur „Domain existiert nicht“ und interpretiert das als eigenes Problem. Die Diagnose, dass es sich um einen TLD weiten Validierungsfehler handelt, erfordert dig Aufrufe mit speziellen Flags und kryptografisches Hintergrundwissen. Das machen die wenigsten Endnutzer.
DENIC hat den Vorfall nicht offiziell acknowledged. Solange der zentrale Betreiber nicht öffentlich Stellung bezieht, fehlt deutschen Tech Medien der „offizielle“ Aufhänger. Erste Diskussionen liefen primär auf englischsprachigen Plattformen wie Hacker News und LowEndTalk.
Caching maskiert Vorfälle für viele Beobachter. Wer zufällig eine Domain abruft, die noch im Resolver Cache liegt, bekommt eine korrekte Antwort und merkt nichts. Die Wahrnehmung „alles ist down“ stellt sich erst ein, wenn man gezielt mehrere Adressen testet.
Diese Frage stand während des Vorfalls in mehreren Foren im Raum. Die kurze Antwort ist: nein. Die etwas längere Antwort ist aufschlussreicher.
DNSSEC ist explizit dafür gebaut, Manipulationen zu erkennen und im Zweifel die Antwort zu verwerfen. Wenn DNSSEC fehlschlägt, ist das im technischen Sinne kein Versagen, sondern eine korrekt ausgelöste Schutzfunktion. Der Resolver weigert sich, eine möglicherweise manipulierte Antwort weiterzugeben, und gibt stattdessen einen klaren Fehler zurück.
Ein echter DNS Hack würde sich ganz anders zeigen. Dort bekäme man gefälschte, aber valide aussehende Antworten zurück: eine falsche IP Adresse, die zu einer manipulierten Webseite führt, ohne dass der Browser einen Fehler meldet. Genau diesen Angriffstyp sollte DNSSEC verhindern, und das tut es auch.
Die wahrscheinlichsten Ursachen für den Vorfall sind operativer Natur:
In allen drei Fällen ist die Ursache menschlich oder prozessbedingt, nicht angriffsbedingt. Solche Vorfälle sind die Rückseite eines hochautomatisierten Systems: Wenn Automation funktioniert, läuft sie unsichtbar im Hintergrund. Wenn sie patzt, können die Folgen kurzfristig groß sein.
Vorfälle wie dieser sind selten, aber wenn sie passieren, sind sie für Betroffene massiv. Aus der Erfahrung des 5. Mai 2026 lassen sich konkrete operative Lehren ziehen.
Klassische Uptime Checks pingen die HTTP Antwort einer URL und melden grünes Licht, solange der Webserver erreichbar ist. Beim DNSSEC Vorfall am 5. Mai 2026 hätten solche Checks nichts gemeldet, weil der Webserver technisch erreichbar war. Nur die DNS Auflösung scheiterte.
Moderne Monitoring Tools wie DNSPerf, RIPE Atlas oder Catchpoint prüfen DNS Auflösung gegen mehrere Resolver weltweit, mit und ohne DNSSEC Validierung. Solche Checks hätten den Vorfall innerhalb von Minuten erkannt. Für jeden produktiven Webauftritt sollte mindestens ein DNS spezifisches Monitoring laufen.
Wenn ein Kunde anruft mit der Aussage „die Website geht nicht“, ist die richtige erste Frage nicht „haben Sie schon den Browser Cache geleert“, sondern strukturell und systematisch:
Mit diesen vier Fragen lässt sich in unter einer Minute eine erste Hypothese aufstellen, ob es ein lokales Endgerät, ein Provider oder ein TLD/DNS Problem ist.
Bei einem TLD DNSSEC Vorfall wie diesem hilft kein Hosting Wechsel, kein Cache Reset und kein Anbieter Anruf. Ein praktischer Notfall Workaround ist die hosts Datei des eigenen Rechners. Sie wird vor jeder DNS Anfrage geprüft und kann mit einer manuellen Zuweisung von Domain zu IP Adresse gefüllt werden.
Auf Windows liegt sie unter C:\Windows\System32\drivers\etc\hosts, auf macOS und Linux unter /etc/hosts. Ein Eintrag wie 148.230.106.240 onlinewachsen.de www.onlinewachsen.de lässt den Browser die Domain direkt auflösen, ohne den DNS Resolver zu befragen. Wichtig dabei: Diese Einträge nach dem Vorfall wieder entfernen, sonst hat man in einigen Wochen veraltete IPs und merkwürdige Fehler.
Auf Domain Ebene lassen sich solche Vorfälle nicht verhindern, weil sie auf TLD Ebene passieren. Aber für andere DNS Vorfälle (etwa Ausfälle eines einzelnen Hosters) gilt: Mehrere Nameserver bei unterschiedlichen Anbietern erhöhen die Resilienz. Konkret bedeutet das, beispielsweise primäre Nameserver beim Hoster und sekundäre Nameserver bei einem unabhängigen DNS Provider wie Cloudflare oder AWS Route 53.
Ein einmaliges Resilience Audit der eigenen DNS Konfiguration ist eine sinnvolle Investition. Geprüft wird dabei: Anzahl und geografische Verteilung der Nameserver, DNSSEC Konfiguration, TTL Hygiene (zu lange TTLs sind bei Wechseln problematisch, zu kurze erhöhen die Last), MX Record Failover.
Im Agenturkontext ist die beste Kommunikationsstrategie bei solchen Vorfällen, betroffenen Kunden zuvorzukommen. Eine Sammelnachricht im Stil von „Wir haben einen .de-weiten DNSSEC Vorfall identifiziert, Eure Seite ist davon betroffen, hier sind die Details, hier was wir tun“ stärkt das Vertrauen wesentlich mehr als reaktives Krisenmanagement, wenn der Kunde anruft. Vertrauen wird in Krisen aufgebaut, nicht in ruhigen Zeiten.
DNSSEC (Domain Name System Security Extensions) ist eine Sicherheitserweiterung für das Domain Name System, die DNS Antworten kryptografisch signiert. Dadurch können Resolver erkennen, ob eine Antwort manipuliert wurde, und sie im Zweifel verwerfen. DNSSEC schützt damit gegen Angriffsklassen wie DNS Spoofing und Cache Poisoning. Etwa 38 Prozent aller weltweiten DNS Anfragen werden inzwischen DNSSEC validiert, in Deutschland deutlich mehr.
Wenn Ihre Domain auf .de endet und Endnutzer am 5. Mai 2026 zwischen 21:40 und 23:30 Uhr MESZ die Fehlermeldung DNS_PROBE_FINISHED_NXDOMAIN gemeldet haben, war Ihre Domain mit hoher Wahrscheinlichkeit betroffen. Auf .com, .info oder .org TLDs bestand kein Problem.
Weil DNS Resolver Antworten zwischenspeichern. Häufig besuchte Seiten wie heise.de oder telekom.de waren bei den meisten Resolvern noch frisch im Cache, also lieferten die Resolver die alte (gute) Antwort. Weniger frequentierte Domains mussten beim TLD Server neu nachfragen und bekamen die fehlerhafte Signatur.
Nein. DNSSEC verhindert weit häufiger reale Angriffe, als es solche operativen Vorfälle verursacht. Der letzte vergleichbare TLD weite Vorfall war 2010. Solche Ereignisse sind extrem selten, während DNS Manipulationen, gegen die DNSSEC schützt, regelmäßig in der Wildbahn dokumentiert werden. Die Antwort ist nicht weniger DNSSEC, sondern besseres Monitoring.
Erstens prüfen, ob die Ursache wirklich global ist. Zweitens proaktiv Kunden und Stakeholder informieren, dass der Vorfall identifiziert ist und nicht beim eigenen Hosting liegt. Drittens als Notfall Workaround einen hosts Datei Eintrag mit der korrekten IP Adresse setzen, damit zumindest der eigene Rechner die Seite erreicht. Viertens einen DENIC Vorfall Report unter dbs@denic.de einreichen, falls der offizielle Status den Vorfall nicht erfasst.
DENIC eG ist die genossenschaftlich organisierte Registrierungsstelle für alle Domains unterhalb der Top Level Domain .de. Sie verwaltet aktuell mehr als 17 Millionen .de-Domains und betreibt 16 Servicestandorte für die Auflösung. Mehr Informationen finden sich auf der DENIC Website.
Selten. Der letzte vergleichbare .de-weite Vorfall war im Mai 2010, also 16 Jahre vor dem aktuellen Ereignis. Solche Vorfälle sind so rar, dass sie als Maßstab für DNS Stabilität gelten. Andere TLDs wie .com oder .org haben in den letzten 20 Jahren ebenfalls vereinzelte DNSSEC Vorfälle gehabt, durchschnittlich aber weniger als einen pro Jahr.
Nein. DNSSEC schützt vor Manipulationen der DNS Antworten, also vor DNS Spoofing und Cache Poisoning. Es schützt nicht vor DDoS Angriffen auf Nameserver, vor BGP Hijacking ganzer IP Bereiche oder vor Account Takeover beim Registrar. Eine umfassende Domain Sicherheitsstrategie kombiniert DNSSEC mit Registrar Lock, sicheren Anmeldeverfahren beim DNS Provider und Multi NS Setup.
Der 5. Mai 2026 hat gezeigt, wie verletzlich auch hochstabile Internet Infrastruktur sein kann, wenn ein einzelner kryptografischer Prozess in einer kritischen Zone schiefgeht. Zwei Stunden weltweite Teilausfälle der zweitgrößten Länder TLD wegen einer einzigen fehlerhaften RRSIG Signatur sind ein eindrückliches Beispiel dafür, dass Automation und Komplexität immer auch neue Fehlerklassen einführen.
Für Webseitenbetreiber und Agenturen ist die zentrale Lehre dennoch beruhigend: Solche Vorfälle sind extrem selten, der letzte vergleichbare Fall war 16 Jahre alt. DNSSEC bleibt eine sinnvolle und wichtige Schutzschicht gegen DNS Manipulationen, gegen die ohne DNSSEC praktisch keine Verteidigung existiert. Die Antwort auf den Vorfall ist nicht weniger DNSSEC, sondern besseres Monitoring und strukturierte Reaktionspfade.
Wer als Agentur oder Webseitenbetreiber jetzt aktiv wird, sichert sich gleich mehrere Vorteile. Erstens ein DNS Monitoring, das auch DNSSEC Fehler erkennt und nicht nur HTTP Verfügbarkeit. Zweitens dokumentierte Diagnose Pfade für künftige Vorfälle, sodass im Ernstfall in Minuten statt Stunden klar ist, wo das Problem liegt. Drittens proaktive Kundenkommunikation als Vertrauensbaustein, der gerade in Krisen wirksam ist.
Bei onlinewachsen begleiten wir Unternehmen durch genau solche Resilienz Themen. Unsere Scaling Dienstleistungen verbinden Webdesign, klassisches SEO und technische Infrastruktur Beratung. Oder kontaktiere uns direkt für ein Erstgespräch zur Resilienz Bewertung deiner Domain Konfiguration.
