Was ist DNSSEC?

DNSSEC (Domain Name System Security Extensions) ist eine Sammlung von IETF-Spezifikationen (RFC 4033, RFC 4034 und RFC 4035, veröffentlicht im März 2005), die DNS-Einträgen kryptografische Signaturen hinzufügt. Ohne DNSSEC kann ein Resolver nicht verifizieren, ob eine DNS-Antwort tatsächlich vom autoritativen Server stammt und nicht unterwegs manipuliert wurde, wodurch Angriffe wie Cache Poisoning, DNS Spoofing und Man-in-the-Middle-Angriffe möglich werden. Mit DNSSEC wird jedes Record Set (A, AAAA, MX, TXT und so weiter) mit einem privaten Schlüssel des Zoneninhabers signiert, und Resolver validieren die Signatur mit dem zugehörigen öffentlichen Schlüssel. Die Root-Zone ist seit dem 15. Juli 2010 signiert. Stand 2025 unterstützen mehr als 90 Prozent der länderspezifischen Top-Level-Domains und alle großen generischen TLDs (com, net, org, info, biz) DNSSEC, wobei die Adoption auf Endkundenebene stark schwankt: Niederlande, Schweden, Tschechien und Norwegen liegen über 60 Prozent, viele andere Länder unter 5 Prozent.

Wie funktioniert DNSSEC?

Jede DNSSEC-fähige Zone veröffentlicht eine Vertrauenskette aus vier Record-Typen:

• DNSKEY: die öffentlichen Schlüssel der Zone. Üblich sind zwei Schlüssel: ein Zone Signing Key (ZSK), der die eigentlichen Records signiert, und ein Key Signing Key (KSK), der das DNSKEY-Set signiert.
• RRSIG: die digitale Signatur, die an jedes Record Set angehängt wird, erzeugt mit dem ZSK.
• DS (Delegation Signer): ein Hash des Child-Zone-KSK, veröffentlicht in der Parent Zone. Der DS-Eintrag verbindet eine Domain mit ihrer TLD und bildet die globale Vertrauenskette.
• NSEC oder NSEC3: beweist die Nichtexistenz eines Eintrags (authenticated denial of existence). NSEC3 ist die datenschutzfreundliche Variante, die Namen hasht, damit Zone Walking nicht trivial ist.

Der validierende Resolver beginnt an der Root, prüft den Root-KSK gegen einen eingebauten Trust Anchor (Root Key, zuletzt im Oktober 2018 von KSK 19036 auf KSK 20326 gewechselt), und folgt der Kette über die TLD (zum Beispiel .de) bis zur angefragten Zone. Fehlt oder stimmt eine Signatur nicht, gibt der Resolver SERVFAIL zurück und der Nutzer sieht einen generischen DNS-Fehler.

Welche Angriffe verhindert DNSSEC?

• Cache Poisoning: bekannt durch den Kaminsky-Angriff 2008. Ein Angreifer schiebt gefälschte Antworten in den Resolver-Cache, sodass bank.de auf eine IP des Angreifers zeigt.
• DNS Spoofing in öffentlichem WLAN oder bei einem feindlichen ISP, wo ein Man-in-the-Middle Antworten manipuliert.
• Folgen von BGP-Hijacks: wenn ein Angreifer die Route zu einem DNS-Provider übernimmt, können die gefälschten Antworten nicht korrekt signiert werden.
• Kompromittierter autoritativer Server: nur eingeschränkt. Stiehlt der Angreifer auch die privaten Schlüssel, hilft DNSSEC nicht mehr.

Was DNSSEC NICHT leistet

• Es verschlüsselt DNS-Anfragen nicht. Wer den Netzwerkpfad beobachten kann, sieht weiterhin, welche Domains aufgerufen werden. Für Vertraulichkeit braucht es DNS over HTTPS (DoH, RFC 8484) oder DNS over TLS (DoT, RFC 7858).
• Es schützt nicht die letzte Meile zwischen Resolver und Client, außer der Client validiert selbst. Die meisten Betriebssysteme überlassen das dem Resolver.
• Es stoppt keine DDoS-Angriffe gegen die DNS-Infrastruktur. DNSSEC verschärft sogar Amplification-Attacken, weil signierte Antworten viel größer sind.
• Es authentifiziert nicht die Website. Das macht TLS. DNSSEC und HTTPS ergänzen sich.

Wie aktiviere ich DNSSEC für meine Domain?

1. Einen DNS-Provider wählen, der DNSSEC unterstützt. Cloudflare, AWS Route 53 (seit Dezember 2020), Google Cloud DNS, Azure DNS (seit 2024), DNSimple, Hurricane Electric und fast alle Registrare (Namecheap, Gandi, OVH, INWX, Hetzner, Porkbun) unterstützen es.
2. Im DNS-Provider-Panel DNSSEC für die Zone aktivieren. Der Provider erzeugt KSK und ZSK und beginnt automatisch zu signieren.
3. Den DS-Eintrag (Digest, Key Tag, Algorithmus, Digest-Typ) aus dem Provider-Panel kopieren.
4. Im Registrar-Konto (wo die Domain registriert ist) im DNSSEC-Bereich den DS-Eintrag einfügen. Dieser Eintrag wird in der Parent-TLD-Zone veröffentlicht und schließt die Vertrauenskette.
5. Bis zu 48 Stunden auf die Propagation warten. Validieren mit dig +dnssec deinedomain.de A und prüfen, ob RRSIG-Einträge vorhanden sind und das AD-Flag im Header gesetzt ist.

Wie prüfe ich DNSSEC für eine Domain?

• Online: DNSViz (dnsviz.net), Verisign DNSSEC Debugger, Internet.nl, MxToolbox DNSSEC Test.
• Kommandozeile: dig +dnssec example.de oder delv example.de (mit BIND ausgeliefert).
• Browser: die Erweiterung "DNSSEC/TLSA Validator" von CZ.NIC zeigt den Status für Firefox und Chrome an.

Eine korrekt signierte Domain liefert RRSIG-Einträge und das AD-Flag im Antwort-Header. Ein kaputtes DNSSEC-Setup gibt SERVFAIL zurück und macht die Domain komplett unerreichbar, daher zuerst auf einer Staging-Domain testen.

Welche kryptografischen Algorithmen nutzt DNSSEC?

Für neue Setups in 2025 sind ECDSA P-256 (Algorithmus 13) oder Ed25519 (Algorithmus 15) empfohlen. Sie liefern viel kleinere Signaturen als RSA, was die Antwortgröße reduziert und beim EDNS0-4096-Byte-UDP-Limit hilft.

Was ist Key Rollover?

DNSSEC-Schlüssel müssen regelmäßig rotiert werden. Üblich ist ein ZSK-Wechsel alle 1 bis 3 Monate und ein KSK-Wechsel alle 1 bis 2 Jahre. ZSK-Rollover passiert automatisch innerhalb der Zone. KSK-Rollover erfordert eine Aktualisierung des DS-Eintrags beim Registrar und ist aufwändiger, weil die Parent Zone den neuen DS veröffentlicht haben muss, bevor der alte Schlüssel außer Dienst geht. Der Root-Zone-KSK wurde im Oktober 2018 erstmals gerollt (KSK 19036 auf KSK 20326). Der nächste Root-KSK-Rollover ist von der ICANN für 2026 oder 2027 geplant.

Was ist der Bezug zwischen DNSSEC und DANE?

DANE (DNS-based Authentication of Named Entities, RFC 6698, August 2012) nutzt DNSSEC-signierte TLSA-Einträge, um TLS-Zertifikats-Fingerprints im DNS zu veröffentlichen. Damit können Clients ein TLS-Zertifikat gegen die Erklärung des Domaininhabers im DNS prüfen und das öffentliche CA-System umgehen. DANE für SMTP ist verbreitet (Deutschland seit 2014 mit Mail.de, Posteo, Mailbox.org; die EU-eIDAS-Verordnung referenziert es). DANE für HTTPS hat sich in Browsern nie durchgesetzt, weil kein großer Browser es implementiert hat.

Welcher Bezug besteht zwischen DNSSEC und DNS over HTTPS (DoH)?

• DNSSEC sorgt dafür, dass die DNS-Antwort echt ist (vom Zoneninhaber signiert).
• DoH sorgt dafür, dass die DNS-Anfrage verschlüsselt übertragen wird und auf dem Netzwerkpfad nicht mitgelesen werden kann.

Für volle DNS-Sicherheit und Privatsphäre sollten beide kombiniert werden. Cloudflare 1.1.1.1, Google 8.8.8.8 und Quad9 9.9.9.9 führen DNSSEC-Validierung durch und bieten DoH/DoT.

Häufige DNSSEC-Fehler

• DS-Eintrag beim Registrar nach einem Key Rollover nicht aktualisieren, wodurch die Vertrauenskette bricht.
• Provider-Wechsel ohne Multi-Signer-DNSSEC oder ohne vorübergehende Deaktivierung von DNSSEC, was zu Ausfällen führt.
• Algorithmus wählen, der nicht von allen Resolvern unterstützt wird.
• Signatur-Ablauf nicht überwachen. Signaturen haben ein Gültigkeitsfenster (typisch 7 bis 30 Tage) und die Zone muss vor Ablauf neu signiert werden.
• DNSSEC als Ersatz für HTTPS oder für E-Mail-Authentifizierung sehen.

Wie hilft InspectWP bei DNSSEC?

InspectWP fragt die DNS-Einträge jeder analysierten Domain ab und meldet, ob die Antwort DNSSEC-Signaturen und eine gültige Vertrauenskette tragen. Domains ohne DNSSEC werden im Sicherheits- und DNS-Bereich des Reports markiert.