Ausfall der .de-Registry: Was der große DNS-Zusammenbruch uns verraten hat

Im Mai 2025 brach im deutschen Netz einiges zusammen. Amazon.de war offline. Telekom-Dienste weg. DHL, die Bahn, Spiegel – alle nicht erreichbar. Server liefen einwandfrei. Domains waren registriert. DNS-Zeiger stimmten. Überwachungsdashboards zeigten Grün. Trotzdem starrten Millionen Nutzer auf Timeouts.

Der Fehler lag tiefer, als alle suchten.

Der unsichtbare Knackpunkt

Registry-Ausfälle sind wie Risse im Fundament – da hilft kein neuer Anstrich. DENIC, die .de-Registry, hatte eine neue Generation ihrer Infrastruktur gestartet. Frischer Code, Sicherheitschecks bestanden, Tests durch. Am 5. Mai lief die geplante Key-Rotation – und alles kippte.

Kurz zum Technikteil: Das System sollte einen Krypto-Key für DNSSEC erzeugen und auf drei Security-Geräte verteilen. Routine für DNSSEC, das DNS-Antworten kryptografisch prüft. So erkennt man echte Domains vor Fakes.

Stattdessen spuckte der Code drei verschiedene Keys aus. Einer landete öffentlich, die anderen signierten weiter – inkompatibel. Folge: Zwei Drittel der .de-DNSSEC-Signaturen ungültig. Resolver wie Google (8.8.8.8), Cloudflare (1.1.1.1) oder Quad9 warfen alles raus und gaben Fehler.

Das Problem mit der Überwachung

DENICs Tools merkten es sofort. Drei Systeme warnten innerhalb von Minuten. Dann? Funkstille. Drei Stunden später war es behoben – aber nicht von DENIC zuerst.

Das zeigt ein Muster: Automatische Alarme ohne schnelle Reaktion sind nutzlos. Sie täuschen Sicherheit vor. Grüne Dashboards lügen, bis der Schaden da ist. Millionen Betroffene, Stunden Verzögerung.

Warum nicht alle gleich litten – und das ist riskant

Der Ausfall traf ungleich. Manche hatten Totalausfall, andere nichts. Grund: Der DNS-Resolver.

Moderne wie Cloudflare oder Google prüfen DNSSEC streng – ungültig? Weg damit. Alte ISP-Resolver? Viele ignorieren DNSSEC und liefern einfach. Omas Internet lief, Tech-Firmen crashten – je nach Resolver-Einstellung.

Das offenbart das Problem: Sicherheit nutzt nur, wenn alle mitmachen. Sonst verstärkt sie Ausfälle statt sie zu stoppen.

Lektion für DNS-Sicherheit

Bei .de nutzen nur 3,6 Prozent DNSSEC – rund 645.000 von 17,9 Millionen Domains. Deshalb traf es vor allem große, DNSSEC-fähige Sites mit validierenden Resolvern. Kleine liefen weiter.

Wahrheit: Je mehr DNSSEC kommt (und das muss), desto schlimmer werden solche Pannen. Übergang schmerzt immer.

Tipps für eure Domain-Strategie

Für kritische Domains ändert das euren DNS-Ansatz:

Mehrere Resolver nutzen. Nicht auf einen setzen. Wechselt automatisch, überwacht, welchen ihr wirklich habt.

Registry-Prozesse checken. Jede ccTLD ist anders. Kennt DENICs Eskalation – ihr Bericht war offen, aber der Alarm-Verzug peinlich.

DNSSEC einsetzen, aber prüfen. Der Ausfall kam durch DNSSEC-Fehler. Deshalb nicht skippen, sondern Tests und schnelle Reaktion fordern.

Richtig überwachen. Hosting-Grün heißt nichts, wenn die Registry hängt. Registry-Checks einbauen, z. B. via Cloudflare.

Cloudflares Rolle

Cloudflare fixte es zuerst – kein Zufall. Ihr 1.1.1.1 war betroffen, globale Server halfen, das Problem zu isolieren. Sie sehen DNS-Pannen im Großen.

Deshalb zählt beim DNS-Provider mehr als "funktioniert es?". Gute sehen Netzwerk-weit und orten Fehler früh.

Was DENIC geändert hat

Neues Key-Rotation-Verfahren. Bessere Alarm-Eskalation. Code gefixt, nicht alles rausgerissen. Überwachung aufgerüstet.

Langweilig? Ja. Aber es stoppt den nächsten Dreistunden-Albtraum.

Der Kernpunkt

Registries sind blind, weil unsichtbar. Registrar und ccTLD kümmern sich. Ihr macht Records und Hosting.

Aber Ketten reißen an Schwachstellen. Kennt Registrar-Status, Resolver-Leistung, Registry-Reaktion. .de zeigt: DNS-Sicherheit nicht outsourcen. Versteht die Schichten darunter, auch wenn andere sie betreiben.

Das ist die Lektion vom 5. Mai 2025: Kritische Pannen passen genau dort, wo ihr nicht hinschaut – drum schaut hin.