Was der .de-Ausfall vom 5. Mai für IT-Verantwortliche bedeutet

Gegen 21:40 Uhr bemerkten erste Nutzer, dass .de-Websites nicht mehr aufrufbar waren. Im Browser erschien die Fehlermeldung DNS_PROBE_FINISHED_NXDOMAIN, so als würde die aufgerufene Domain schlicht nicht existieren. Dabei liefen die eigentlichen Webserver völlig normal weiter. Das Problem lag eine Ebene darunter: im Domain Name System (DNS), dem Verzeichnis, das Domainnamen in IP-Adressen übersetzt.

Erst um 23:28 Uhr veröffentlichte die DENIC eine erste offizielle Incident-Meldung auf ihrer Statusseite und sprach von einer "Partial Service Disruption". Reparaturarbeiten liefen bereits auf Hochtouren: Um 00:08 Uhr begann die Verteilung korrigierter Zonendaten, gegen 01:15 Uhr erklärte die DENIC den regulären Betrieb für wiederhergestellt. Die vollständige Entwarnung folgte am Morgen des 6. Mai. Dennoch bemerkten viele Nutzer noch Stunden länger Einschränkungen, weil zwischengespeicherte ("gecachte") Fehlerantworten sich nur langsam aus den weltweiten DNS-Systemen herauslösen.

Zu den bekanntermaßen betroffenen Domains zählten bahn.de, spiegel.de, DHL-Dienste sowie Websites von Sparkassen, Aldi und unzähligen weiteren Unternehmen. Es war nach aktuellem Kenntnisstand der schwerwiegendste DNS-Vorfall für die .de-Zone seit mehr als einem Jahrzehnt.

Der Auslöser war kein Angriff und kein Hardwareausfall, sondern ein Fehler bei einem routinemäßigen Sicherheitsvorgang: dem sogenannten Zone-Signing-Key-Rollover (ZSK-Rollover). Um zu verstehen, was das bedeutet, ist ein kurzer Blick auf DNSSEC hilfreich.

DNSSEC steht für Domain Name System Security Extensions. Es ist eine Erweiterung des klassischen DNS, die DNS-Antworten kryptografisch signiert. Ziel ist es, sogenannte DNS-Spoofing- und Cache-Poisoning-Angriffe zu verhindern – also Szenarien, in denen ein Angreifer Nutzer auf gefälschte Webseiten umlenkt. Empfängt ein DNSSEC-validierender Resolver eine DNS-Antwort, prüft er deren digitale Signatur anhand einer Vertrauenskette ("Chain of Trust"), die bis zur Root-Zone des Internets zurückreicht. Ist diese Kette irgendwo unterbrochen, verwirft er die Antwort – und gibt stattdessen die Fehlermeldung SERVFAIL zurück.

Genau das geschah am 5. Mai. Die DENIC wechselt ihren Zone Signing Key, den "Arbeitsschlüssel", mit dem die .de-Zone signiert wird – standardmäßig alle fünf Wochen automatisch. Bei diesem turnusmäßigen Wechsel gelangte eine kryptografisch ungültige Signatur (ein RRSIG-Record) in die produktive .de-Zone. Konkret: Ein NSEC3-Record wurde mit einem Schlüssel signiert, dessen zugehöriger öffentlicher Schlüssel im System nicht korrekt hinterlegt war. Für jeden DNSSEC-validierenden Resolver weltweit war die Konsequenz zwingend und unvermeidlich: Antwort verwerfen, SERVFAIL zurückgeben, Domain nicht erreichbar.

Da der Fehler nicht bei einer einzelnen Domain, sondern auf Ebene der gesamten .de-Zone lag, waren potenziell sämtliche DNSSEC-signierten .de-Domains betroffen, ein klassischer Single-Point-of-Failure auf der obersten Hierarchiestufe. DENIC behob das Problem durch einen gezielten neuen Signierungsvorgang mit einem korrekt veröffentlichten Schlüssel. Eine ausführliche Post-Mortem-Analyse hat die DENIC angekündigt; zum Zeitpunkt der Erstellung dieses Artikels steht sie noch aus.

Betroffen waren ausschließlich Nutzer, deren DNS-Resolver DNSSEC-Signaturen aktiv prüfen. Das betrifft alle großen öffentlichen DNS-Dienste: Cloudflare (1.1.1.1), Google (8.8.8.8) und Quad9 (9.9.9.9). Wer in seinem Unternehmen oder Router diese Resolver konfiguriert hatte, meist aus gutem Sicherheitsbewusstsein heraus, konnte in der Störungszeit keine .de-Domains mehr erreichen.

Nicht betroffen hingegen waren Nutzer, deren ISP-Resolver DNSSEC nicht validiert. Einige klassische deutsche Provider-Resolver verzichten auf diese Prüfung und ihre Kunden merkten in der Störungsnacht schlicht gar nichts. Das Paradoxon: Wer mehr IT-Sicherheit eingestellt hatte, war stärker von dem Ausfall betroffen als jemand mit weniger sicherheitsorientierter Konfiguration. Das ist kein Argument gegen DNSSEC, wohl aber ein Argument für mehr Resilienzdenken.

Auch die DENIC-Statusseite (status.denic.de) war während der Störung für einen Teil der Betroffenen ironischerweise nicht erreichbar – denn auch sie liegt unter einer .de-Domain.

Der Vorfall liegt außerhalb der eigenen Kontrolle, die DENIC ist die einzige Instanz, die die .de-Zone betreibt und reparieren kann. Was Unternehmen jedoch in der Hand haben, ist die eigene Vorbereitung auf genau solche Ereignisse. Drei Maßnahmen lassen sich mit vergleichsweise geringem Aufwand umsetzen.

DNS-Monitoring aufsetzen
Wer eine .de-Domain als kritischen Geschäftspunkt betreibt, sollte ein Monitoring haben, das DNSSEC-Validierungsfehler erkennt, bevor Kunden anrufen. Auf Linux- und macOS-Systemen steht dafür das Kommandozeilen-Werkzeug dig zur Verfügung: Der Aufruf "dig +dnssec eigene-domain.de @1.1.1.1" erzwingt die Validierung gegen den Cloudflare-Resolver. Eine saubere Antwort enthält das Flag "ad" (Authenticated Data). Kommt stattdessen SERVFAIL, ist die Trust Chain unterbrochen – genau wie in der Nacht vom 5. Mai.

Unter Windows ist dig nicht nativ verfügbar. Eine direkte Alternative bietet die Installation der BIND-Tools (Berkeley Internet Name Domain) von ISC (Internet Systems Consortium): Nach der Installation steht dig auch unter Windows über die Eingabeaufforderung oder PowerShell zur Verfügung und verhält sich identisch zum Linux-Pendant, inklusive DNSSEC-Validierung und ad-Flag. BIND ist Open Source, weit verbreitet und gilt als Referenzimplementierung für DNS-Software.

Die eigene Resolver-Strategie bewusst wählen

Für interne Netzwerke lohnt es sich, die Frage bewusst zu stellen: Setzt man auf DNSSEC-validierende Resolver (mehr Schutz vor Manipulation, aber anfälliger bei Fehlern wie dem vom 5. Mai) oder auf nicht-validierende Resolver (mehr Verfügbarkeit, dafür ohne Integritätsprüfung)? Eine pauschale Antwort gibt es nicht, aber die Entscheidung sollte dokumentiert und begründet getroffen werden, nicht dem Zufall überlassen. Wichtig: Das Deaktivieren der DNSSEC-Validierung ist allenfalls eine Notlösung für die Dauer eines akuten Ausfalls. Dauerhaft bedeutet der Verzicht darauf, die eigene Infrastruktur für Cache-Poisoning und DNS-Spoofing anfällig zu machen.

Redundanz durch parallele TLD-Präsenz und Eskalationsroute

Unternehmen mit besonders kritischen Online-Diensten sollten prüfen, ob parallele Domains unter anderen Top-Level-Domains sinnvoll sind, etwa .com, .eu oder .net als Fallback, der bei Ausfällen der .de-Zone greift. Mindestens aber sollte eine dokumentierte Eskalationsroute existieren: Wer wird intern informiert, wenn die eigene Domain unerreichbar ist? Wann wird die Kommunikation nach außen aktiviert? Welche alternativen Kontaktwege gibt es für Kunden? Beides – Monitoring und Eskalationsroute – muss eingerichtet sein, wenn die Störung eintritt, nicht erst während sie läuft.

Der Vorfall vom 5. Mai ist kein Argument gegen DNSSEC. Der Mechanismus hat an jenem Abend genau das getan, wofür er konzipiert wurde: Er hat eine kryptografisch ungültige Antwort als solche erkannt und verworfen und damit seine Nutzer vor potenziell manipulierten DNS-Antworten geschützt. Das Problem war nicht DNSSEC selbst, sondern ein Fehler in der Signierungsinfrastruktur einer zentralen Registry. Die richtige Lehre lautet daher nicht, auf DNSSEC zu verzichten, sondern die Abhängigkeit von zentraler Infrastruktur in die eigene Risikobewertung einzubeziehen.

Für IT-Verantwortliche im Mittelstand und deren Dienstleister gilt: Die .de-Zone hat über 17 Millionen registrierte Domains. Wer eine davon als geschäftskritischen Endpunkt betreibt, trägt eine externe Abhängigkeit, die er nicht selbst steuern kann, aber sehr wohl managen. DNS-Monitoring, eine bewusste Resolver-Strategie und eine dokumentierte Notfallkommunikation sind keine exotischen Anforderungen. Sie sind der Unterschied zwischen einem Ausfall, den man bemerkt und strukturiert angeht, und einem, von dem man erst durch Kundenanrufe erfährt.