Am Abend des 5. Mai 2026 war für Millionen Nutzer in Deutschland plötzlich Schluss: Websites mit .de-Endung ließen sich nicht mehr aufrufen, Apps wie die der Deutschen Bahn verweigerten den Dienst, und E-Mails blieben unzugestellt. Die Ursache lag nicht bei einzelnen Hostern oder Providern, sondern tief in der Infrastruktur des Domain Name Systems selbst – genauer gesagt bei einer fehlerhaften DNSSEC-Signatur der .de-Zone.
Der Vorfall zeigt eindrücklich, wie fragil zentrale Internetinfrastruktur sein kann und warum es sich lohnt, die Mechanismen hinter der DNS-Auflösung zu verstehen. In diesem Beitrag ordnen wir ein, was genau passiert ist, welche technischen Zusammenhänge eine Rolle spielen und was du als Website-Betreiber daraus mitnehmen kannst.
 

Inhaltsverzeichnis

Sichere deinen Firmennamen: Mit dogado zur perfekten Domain

Der richtige Firmenname ist deine Markenidentität – die passende Domain macht ihn digital wirksam. Bei dogado reservierst du nicht nur einen Namen, sondern die technische Grundlage für deinen Online-Erfolg. Mit professioneller E-Mail, optimiertem Hosting und persönlicher Unterstützung starten wir deine digitale Präsenz.

Viele bunte, quadratische Kacheln mit Domain-Endungen wie .com, .net, .org, .edu und .co.

Was genau ist am Abend des 5. Mai passiert?

Gegen 21:50 Uhr häuften sich Berichte, dass .de-Domains nicht mehr aufgelöst werden konnten. DNS-Server antworteten auf Anfragen nach .de-Domains mit dem Statuscode NXDOMAIN – das bedeutet, dass die angefragte Domain aus Sicht des DNS-Servers schlicht nicht existiert. Wer zu diesem Zeitpunkt eine .de-Website aufrief, sah im Browser eine Fehlermeldung. Auch Mailprogramme konnten keine Verbindung mehr zu Servern unter .de-Domains herstellen.

Das Besondere an diesem Ausfall: Er war nicht auf einen bestimmten DNS-Anbieter oder Internet-Provider beschränkt. Egal ob du Google DNS (8.8.8.8), Cloudflare (1.1.1.1) oder den DNS-Server deines Providers genutzt hast – das Ergebnis war überall dasselbe. Wer die IP-Adresse seiner Zielseite noch im lokalen DNS-Cache hatte, konnte sie weiterhin erreichen. Für alle anderen war die .de-Zone de facto offline.

Erst in der Nacht auf den 6. Mai, gegen 3:42 Uhr, konnte die DENIC – die als Registrierungsstelle für .de-Domains die zugehörige DNS-Zone verwaltet – die fehlerhafte Signatur erneuern und den Normalbetrieb wiederherstellen.

Die technische Ursache: Eine fehlerhafte RRSIG-Signatur

Um zu verstehen, warum ein einzelner Konfigurationsfehler so weitreichende Folgen haben konnte, lohnt sich ein Blick auf DNSSEC. Das Domain Name Security Extensions-Protokoll wurde entwickelt, um DNS-Antworten kryptografisch abzusichern. Jede DNS-Zone kann ihre Einträge digital signieren. Empfangende DNS-Server, die DNSSEC validieren, prüfen diese Signaturen und verwerfen Antworten, deren Signatur ungültig ist. So soll verhindert werden, dass gefälschte DNS-Antworten Nutzer auf manipulierte Server umleiten.

Im konkreten Fall war der SOA-Eintrag (Start of Authority) der .de-Zone fehlerhaft signiert. Der SOA-Eintrag ist ein zentraler Bestandteil jeder DNS-Zone – er enthält unter anderem Informationen über die primäre Namensserver-Instanz und die Seriennummer der Zone. Die zugehörige RRSIG-Signatur, die die Echtheit dieses Eintrags bestätigen soll, war beschädigt beziehungsweise malformed. Das Kommandozeilenwerkzeug dig lieferte bei einer Abfrage die eindeutige Fehlermeldung: RRSIG with malformed signature found for de/soa.

Da validierende DNS-Server so konzipiert sind, dass sie bei ungültiger Signatur die gesamte Antwort als nicht vertrauenswürdig einstufen, wurde die komplette .de-Zone für diese Server unerreichbar. Das betraf nicht nur Domains, die selbst DNSSEC aktiviert hatten, sondern sämtliche .de-Domains – denn die Validierung findet bereits auf Ebene der übergeordneten Zone statt, bevor die individuelle Domain überhaupt aufgelöst wird.

Warum der Wechsel des DNS-Servers nicht half

Bei DNS-Problemen ist der erste Reflex vieler Nutzer, den DNS-Server zu wechseln – beispielsweise auf Google DNS oder Cloudflare. In diesem Fall war das wirkungslos, da das Problem nicht bei den DNS-Resolvern lag, sondern bei den autoritativen Nameservern der .de-Zone selbst. Jeder validierende Resolver auf der Welt erhielt dieselbe fehlerhafte Signatur und musste die Antwort verwerfen.

Ein Workaround war nur über DNS-Server möglich, die DNSSEC grundsätzlich nicht validieren. Solche Server nehmen die DNS-Antwort entgegen, ohne die kryptografische Signatur zu prüfen, und leiten das Ergebnis an den anfragenden Client weiter. Level 3 betreibt unter den Adressen 4.2.2.1 und 4.2.2.6 solche nicht-validierenden Resolver, ebenso Quad9 unter 9.9.9.10. Wer während des Ausfalls einen dieser Server im Router oder in den Netzwerkeinstellungen eingetragen hat, konnte .de-Domains wieder auflösen.

Cloudflare reagierte im Verlauf des Abends, indem das Unternehmen die DNSSEC-Validierung gezielt für .de-Domains auf seinem Resolver 1.1.1.1 deaktivierte. Das entsprechende Vorgehen ist in RFC 7646 als sogenannter Negative Trust Anchor beschrieben – ein definiertes Verfahren, um bei fehlerhaften DNSSEC-Signaturen gezielt die Validierung für bestimmte Zonen auszusetzen.

Die Reaktion der DENIC

Die DENIC veröffentlichte gegen 22:55 Uhr eine erste Statusmeldung auf ihrer Website, in der von einer Partial Service Disruption die Rede war. Ein ausführlicheres Update folgte um 23:28 Uhr. Darin bestätigte die DENIC, dass alle DNSSEC-signierten .de-Domains in ihrer Erreichbarkeit betroffen seien. Diese Formulierung war allerdings unpräzise: Tatsächlich waren auch .de-Domains betroffen, die selbst kein DNSSEC aktiviert hatten, da die fehlerhafte Signatur auf Ebene der übergeordneten .de-Zone lag.

Die DENIC teilte zudem mit, dass die genaue Ursache noch nicht vollständig identifiziert sei und die technischen Teams intensiv an Analyse und Wiederherstellung arbeiteten. Ein bemerkenswertes Detail am Rande: Als Kontaktweg verwies die DENIC auf die üblichen Kanäle – was insofern problematisch war, als E-Mails an Adressen unter denic.de zu diesem Zeitpunkt ebenfalls nicht zustellbar waren.

Was Website-Betreiber aus dem Vorfall lernen können

Dieser Ausfall lag vollständig außerhalb des Einflussbereichs einzelner Website-Betreiber. Trotzdem gibt es Lehren, die sich daraus ziehen lassen.

DNS-Caching und TTL-Werte bewusst konfigurieren

Websites, deren DNS-Einträge mit längeren TTL-Werten (Time to Live) konfiguriert waren, blieben während des Ausfalls für einige Nutzer länger erreichbar – nämlich solange die Einträge noch im Cache der Resolver lagen. Extrem niedrige TTL-Werte, wie sie manchmal für schnelle DNS-Änderungen gesetzt werden, führen dazu, dass ein solcher Ausfall deine Website schneller unerreichbar macht. Es lohnt sich, die TTL-Konfiguration deiner Domain bewusst abzuwägen.

Monitoring auf DNS-Ebene einrichten

Viele Monitoring-Systeme prüfen lediglich, ob ein Webserver antwortet. Ein DNS-Ausfall wie dieser wird dabei unter Umständen nicht korrekt erkannt, da der Monitoring-Server die Domain ebenfalls nicht mehr auflösen kann. Externe Monitoring-Dienste, die von verschiedenen Standorten aus prüfen und auch DNS-spezifische Checks durchführen, liefern in solchen Szenarien aussagekräftigere Ergebnisse.

Notfallkommunikation ohne die eigene Domain

Wenn deine primäre Domain nicht erreichbar ist, funktionieren auch E-Mail-Adressen unter dieser Domain nicht mehr. Für geschäftskritische Kommunikation kann es sinnvoll sein, einen alternativen Kommunikationskanal vorzuhalten – etwa eine E-Mail-Adresse unter einer anderen TLD oder einen Messenger-Kanal für interne Abstimmungen.

Mehrere TLDs als strategische Absicherung

Für Unternehmen, deren Geschäftsbetrieb unmittelbar von der Erreichbarkeit ihrer Website abhängt, kann die Registrierung einer zusätzlichen Domain unter einer anderen TLD – etwa .com, .eu oder .net – als Ausweichoption dienen. Im Ernstfall lässt sich darüber zumindest eine Statusseite oder eine Weiterleitung betreiben.

Domains und DNS-Infrastruktur bei dogado

Die Verfügbarkeit deiner Domain ist das Fundament deiner gesamten Online-Präsenz. Ob Website, E-Mail oder App – ohne funktionierende DNS-Auflösung ist nichts davon erreichbar. Bei dogado kannst du deine Domains registrieren und verwalten, wobei die DNS-Konfiguration direkt über das Kundenpanel steuerbar ist. TTL-Werte, DNS-Einträge und Nameserver-Zuordnungen lassen sich dort gezielt anpassen.

Wenn du deine Website auf einem dogado Webhosting oder VPS betreibst, profitierst du von einer Infrastruktur, die auf Verfügbarkeit ausgelegt ist. In Kombination mit einer strategisch registrierten Zweitdomain unter einer alternativen TLD stellst du sicher, dass du auch bei übergeordneten DNS-Störungen handlungsfähig bleibst. Über dogado E-Mail-Adressen unter einer solchen Zweitdomain sicherst du zusätzlich deine geschäftliche Kommunikation ab.

Für Nutzer, die ihre Website mit dem dogado Homepage-Baukasten oder über WordPress Hosting betreiben, gilt dasselbe Prinzip: Die technische Plattform kann noch so stabil laufen – wenn die DNS-Ebene ausfällt, ist die Seite nicht erreichbar. Eine bewusste Domain-Strategie mit mehreren TLDs ist deshalb keine Übertreibung, sondern gelebtes Risikomanagement.

Bewertung des Beitrages: Ø5,0

Danke für deine Bewertung

Der Beitrag hat dir gefallen? Teile ihn doch mit deinen Freunden & Arbeitskollegen

FacebookFacebook XX LinkedInLinkedIn WhatsApp WhatsApp