DNSSEC: Was steckt dahinter – und wie schaltet man es ab?

Ein Vorfall im Mai 2026 hat gezeigt, wie fragil das Internet werden kann, wenn ein einziges Sicherheitsprotokoll kippt. In der Nacht vom 5. auf den 6. Mai 2026 waren für mehrere Stunden Millionen von .de-Domains nicht erreichbar – der Grund: ein DNSSEC-Fehler bei der DENIC, der zentralen Registrierstelle für deutsche Domains. Zeit, sich das Thema genauer anzuschauen: Was ist DNSSEC überhaupt, was bringt es – und wie kommt man bei Bedarf wieder davon los?

Was ist DNSSEC?

Das Internet funktioniert im Hintergrund wie ein gigantisches Telefonbuch: Wenn du "beispiel.de" in deinen Browser eingibst, übersetzt das DNS (Domain Name System) diesen Namen in eine IP-Adresse, z. B. 93.184.216.34. Erst dann weiß dein Rechner, wohin er die Anfrage schicken soll. Das Problem dabei: Das klassische DNS wurde in den 1980er-Jahren entwickelt, zu einer Zeit, in der Sicherheit keine Rolle spielte. Es gibt keinerlei Überprüfung, ob die Antwort, die du bekommst, wirklich vom richtigen Server stammt – oder ob sie jemand manipuliert hat.

Genau hier setzt DNSSEC (Domain Name System Security Extensions) an. DNSSEC fügt dem DNS eine Schicht kryptografischer Signaturen hinzu: Jeder DNS-Eintrag wird mit einem privaten Schlüssel signiert, und der zugehörige öffentliche Schlüssel ist ebenfalls im DNS hinterlegt. Ein validierender Resolver kann damit überprüfen, ob eine Antwort echt ist und vom autorisierten Nameserver stammt – und nicht von einem Angreifer in der Leitung.

Das Modell funktioniert als sogenannte Vertrauenskette (Trust Chain): angefangen beim Root-Nameserver über die Top-Level-Domain (.de, .com etc.) bis hin zur eigentlichen Domain. Jeder Schritt in dieser Kette wird durch digitale Signaturen abgesichert. Bricht irgendwo in dieser Kette eine Signatur, verweigert ein validierender Resolver die Antwort – und der Nutzer sieht eine Fehlermeldung oder die Seite ist einfach nicht erreichbar.

Vorteile von DNSSEC

DNSSEC bietet echten Schutz gegen bestimmte, gefährliche Angriffsszenarien:

• Schutz vor DNS-Spoofing und Cache Poisoning: Ein Angreifer kann keine gefälschten DNS-Antworten einschleusen, die Nutzer auf Phishing-Seiten umleiten – die Signatur würde sofort auffallen.
• Schutz vor dem Kaminsky-Angriff: Die berühmte Schwachstelle von 2008 zeigte, wie einfach DNS-Caches vergiftet werden können. DNSSEC macht solche Angriffe auf signierte Zonen grundsätzlich unwirksam.
• Grundlage für erweiterte Sicherheit: Protokolle wie DANE (DNS-Based Authentication of Named Entities) bauen auf DNSSEC auf und erlauben es, TLS-Zertifikate direkt im DNS zu verankern – unabhängig von klassischen Zertifizierungsstellen.
• Nachweisliche Datenintegrität: Resolver und Anwendungen können sicher sein, dass DNS-Daten nicht auf dem Weg manipuliert wurden.

Nachteile und Risiken von DNSSEC

So sinnvoll DNSSEC im Prinzip ist – in der Praxis bringt es auch erhebliche Tücken mit sich:

• Größere DNS-Antworten: Kryptografische Signaturen fügen pro Datensatz rund 500 Byte hinzu. Das erhöht den Bandbreitenverbrauch und kann dazu führen, dass Antworten nicht mehr per UDP übertragen werden können, sondern auf das langsamere TCP zurückfallen.
• Komplexität bei der Verwaltung: DNSSEC erfordert regelmäßige Schlüsselwechsel (sogenannte Key Rollovers). Wird dieser Prozess falsch ausgeführt, kann die gesamte Domain unerreichbar werden – genau das, was bei der DENIC passiert ist.
• Fehlkonfigurationen treffen alle: Wenn nicht der eigene Nameserver, sondern eine übergeordnete Stelle (wie eine TLD-Registry) einen Fehler macht, sind alle betroffenen Domains offline – obwohl sie selbst nichts falsch gemacht haben.
• Kein Schutz vor allem: DNSSEC sichert nur die Integrität von DNS-Daten ab. Es schützt nicht die Übertragung selbst (dafür gibt es DNS over HTTPS/TLS) und auch nicht vor einem kompromittierten Nameserver.
• Amplifikationspotential für DDoS: Offene Resolver mit DNSSEC können Reflection-Angriffe im Vergleich zu einfachem DNS um den Faktor 50 oder mehr verstärken.

Der DENIC-Vorfall vom 5. Mai 2026: Ein Lehrstück in Sachen Kettenreaktion

Am Abend des 5. Mai 2026 gegen 22:00 Uhr wurden in Deutschland Millionen von .de-Domains plötzlich unerreichbar. Der Auslöser: Die DENIC hatte beim Wechsel des Zone-Signing-Keys (ZSK-Rollover) eine ungültige RRSIG-Signatur für den SOA-Eintrag der gesamten .de-Zone publiziert. Damit war die Trust Chain an der Wurzel gebrochen – alle validierenden Resolver weltweit, inklusive Google DNS (8.8.8.8), Cloudflare (1.1.1.1) und Quad9 (9.9.9.9), antworteten mit SERVFAIL.

Das Perfide daran: Betroffen waren nicht nur DNSSEC-signierte Domains, sondern faktisch alle .de-Domains – weil die fehlerhafte Signatur auf TLD-Ebene lag und damit jeden Auflösungsversuch vergiftete. Technisch versierte Nutzer, die ihren Resolver kurzfristig auf einen DNS-Server ohne DNSSEC-Validierung umgestellt hatten, kamen hingegen problemlos ans Ziel.

Um 00:08 Uhr am 6. Mai begann die DENIC die korrigierte DNS-Zone auszurollen. Um 01:15 Uhr war der Betrieb wiederhergestellt, bis um 03:42 Uhr war auch die DNSSEC-Signatur vollständig erneuert. Da DNS-Einträge aber weltweit in Caches liegen, dauerte es noch einige Stunden, bis alle Resolver wieder korrekt antworteten. Ein DNS-Cache-Flush oder ein Resolver-Neustart konnte in dieser Phase helfen.

Der Vorfall ist kein Einzelfall: Ähnliches ist bereits anderen TLD-Registries passiert. DNSSEC ist eben nicht nur ein Sicherheitsnetz – es ist auch ein komplexer Mechanismus, der bei Fehlern ganze Domain-Landschaften vom Netz nehmen kann.

DNSSEC für die eigene Domain abschalten

Es gibt zwei Ansätze: Entweder du deaktivierst DNSSEC für deine eigene Domain beim Registrar, oder du nutzt als Nutzer (oder Netzwerkbetreiber) einen DNS-Resolver, der keine DNSSEC-Validierung durchführt.

Wichtig: Das Abschalten von DNSSEC muss koordiniert erfolgen. Wenn du einfach die Schlüssel (KSK/ZSK) aus deiner Zonendatei entfernst, ohne dass die Registry (z. B. DENIC) den entsprechenden DS-Eintrag ebenfalls löscht, wird deine Domain für alle validierenden Resolver unerreichbar. Die Trust Chain bricht, und deine Domain gilt als "bogus" (gefälscht).

Der korrekte Ablauf ist immer:

1. Zuerst beim Registrar DNSSEC deaktivieren – nicht in der Zonendatei anfangen.
2. Der Registrar meldet den Widerruf an die Registry (z. B. DENIC).
3. Die Registry löscht den DS-Eintrag aus ihrer Datenbank.
4. Erst dann dürfen die DNSSEC-Schlüssel aus der eigenen Zone entfernt werden.
5. Warte, bis die TTL der alten Einträge abgelaufen ist – erst dann ist der Übergang sicher.

Bei den gängigen deutschen Hostern und Registraren geht das über die jeweilige Verwaltungsoberfläche:

• IONOS: DNS-Einstellungen der Domain -> Bereich "DNSSEC" -> auf "Deaktivieren" klicken. Die DNSSEC-spezifischen Einstellungen werden automatisch entfernt.
• All-Inkl, Strato, Hetzner und die meisten anderen Anbieter: Im Kundenbereich unter Domains -> DNS -> DNSSEC den entsprechenden Schalter umlegen oder die DS-Records löschen.
• Eigener Nameserver (z. B. BIND): Hier zunächst den DS-Record beim Registrar löschen lassen, danach dnssec-policy entfernen oder auto-dnssec maintain deaktivieren und die Zone ohne Signaturen neu laden.

Einen DNS-Resolver ohne DNSSEC-Validierung nutzen

Wenn du als Nutzer oder Systemadministrator kurzfristig auf einen Resolver ohne DNSSEC-Validierung ausweichen willst – etwa weil ein Ausfall wie beim DENIC-Vorfall dies erfordert – gibt es einige Optionen:

Wichtiger Hinweis zu Quad9: Quad9 hat angekündigt, dass ab dem 15. Juni 2026 auch der bisher nicht-validierende Resolver 9.9.9.10 DNSSEC-Validierung aktivieren wird. Ab dann wird es innerhalb des Quad9-Netzwerks keinen Resolver ohne DNSSEC-Prüfung mehr geben. Wer dauerhaft einen nicht-validierenden Resolver benötigt, muss ab diesem Datum auf andere Anbieter ausweichen.

Unter Linux/systemd lässt sich die DNSSEC-Validierung im System-Resolver temporär abschalten:

# /etc/systemd/resolved.conf
[Resolve]
DNSSEC=no

Danach sudo systemctl restart systemd-resolved ausführen. Auf einem Router mit OpenWrt oder einem Pi-hole kann man im Webinterface unter den DNS-Einstellungen die DNSSEC-Validierung ebenfalls deaktivieren.

Fazit: Sicherheit mit Risiken

DNSSEC ist eine sinnvolle Technologie – auf dem Papier. In der Praxis zeigt der DENIC-Vorfall vom Mai 2026 eindrücklich, dass selbst gut gemeinte Sicherheitsmechanismen zum Einfallstor für großflächige Ausfälle werden können, wenn ein Fehler in der Verwaltung passiert. Wer DNSSEC deaktivieren möchte, sollte das koordiniert und nie überstürzt tun. Und wer als Nutzer bei einem solchen Ausfall handlungsfähig bleiben will, sollte wissen, wie er seinen Resolver kurzzeitig auf eine nicht-validierende Alternative umstellt.