DNSSEC (DNS Security Extensions)

DNSSEC (Domain Name Security Extensions) ist eine Sicherheitserweiterung für das Domain Name System, die DNS-Antworten mit kryptografischen Signaturen versieht. Das ursprüngliche DNS-Protokoll aus den 1980er Jahren enthält keinerlei Mechanismen zur Überprüfung der Authentizität von DNS-Antworten. Ein Angreifer, der sich im Netzwerkpfad zwischen Client und Resolver befindet, kann gefälschte DNS-Antworten einschleusen und Nutzer auf schädliche Server umleiten — ein Angriff, der als DNS-Spoofing oder Cache Poisoning bekannt ist. DNSSEC verhindert dies, indem jeder DNS-Record eine überprüfbare Signatur erhält.

Funktionsweise der Vertrauenskette

DNSSEC baut auf einer hierarchischen Vertrauenskette auf, die der Struktur des DNS selbst folgt. An der Spitze steht die DNS-Root-Zone, deren öffentlicher Schlüssel in allen validierenden Resolvern hinterlegt ist. Von dort aus wird das Vertrauen über die Top-Level-Domain (z. B. .de) bis zur einzelnen Domain delegiert.

Jede DNSSEC-geschützte Zone verwendet zwei Schlüsselpaare. Der Key Signing Key (KSK) ist der übergeordnete Schlüssel, dessen Hash als DS-Record (Delegation Signer) in der Elternzone veröffentlicht wird. Der Zone Signing Key (ZSK) signiert die eigentlichen DNS-Records und erzeugt dabei RRSIG-Records (Resource Record Signatures). Der KSK signiert wiederum den ZSK, sodass ein Resolver die gesamte Kette von der Root-Zone bis zum einzelnen A- oder MX-Record lückenlos verifizieren kann.

Wenn ein validierender Resolver eine DNS-Antwort erhält, prüft er zunächst die RRSIG-Signatur gegen den DNSKEY der Zone. Anschließend verifiziert er den DNSKEY gegen den DS-Record der übergeordneten Zone — und so weiter bis zur Root. Nur wenn jedes Glied dieser Kette intakt ist, akzeptiert der Resolver die Antwort als authentisch. Eine einzige fehlerhafte Signatur oder ein fehlender DS-Record führt dazu, dass die gesamte Validierung fehlschlägt.

NSEC und NSEC3: Beweis der Nichtexistenz

Ein einzigartiges Problem, das DNSSEC lösen muss, ist der authentifizierte Beweis, dass ein bestimmter DNS-Name nicht existiert. Ohne diesen Mechanismus könnte ein Angreifer gefälschte NXDOMAIN-Antworten einschleusen und so die Erreichbarkeit legitimer Domains blockieren.

NSEC (Next Secure) war der erste Ansatz: Es listet den alphabetisch nächsten existierenden Namen auf und beweist damit, dass zwischen zwei Namen kein weiterer existiert. Der Nachteil von NSEC ist, dass ein Angreifer durch systematisches Durchlaufen aller NSEC-Records den vollständigen Zoneninhalt rekonstruieren kann — bekannt als Zone Walking.

NSEC3 löst dieses Problem, indem es statt der Klartextnamen gehashte Werte verwendet. Ein Angreifer sieht nur die Hashes und kann die tatsächlichen Domainnamen nicht ohne Weiteres ableiten. Die meisten modernen DNSSEC-Implementierungen setzen NSEC3 ein, insbesondere bei Domains, deren Zoneninhalt nicht öffentlich sein soll. Die Wahl zwischen NSEC und NSEC3 hängt vom Schutzbedarf ab: Für öffentliche Domains ohne sensitive Subdomains ist NSEC ausreichend, während Unternehmen mit interner DNS-Struktur NSEC3 bevorzugen sollten.

Key Rollover und Schlüsselverwaltung

DNSSEC-Schlüssel haben eine begrenzte Lebensdauer und müssen regelmäßig ausgetauscht werden — ein Vorgang, der als Key Rollover bezeichnet wird. Beim ZSK-Rollover wird der Zone Signing Key turnusmäßig ersetzt, typischerweise alle ein bis drei Monate. Da der ZSK nicht in der übergeordneten Zone referenziert wird, ist dieser Vorgang vergleichsweise unkompliziert: Der neue Schlüssel wird zunächst als zusätzlicher DNSKEY veröffentlicht, dann werden die Records mit dem neuen Schlüssel signiert, und schließlich wird der alte Schlüssel entfernt.

Der KSK-Rollover ist aufwendiger, da er eine Aktualisierung des DS-Records in der übergeordneten Zone erfordert. Diese Koordination zwischen der eigenen Zone und dem Registrar beziehungsweise der TLD-Registry muss sorgfältig geplant werden, um Unterbrechungen zu vermeiden. Fehler beim Key Rollover sind in der Praxis eine der häufigsten Ursachen für DNSSEC-Ausfälle — sie führen dazu, dass validierende Resolver die gesamte Domain als ungültig einstufen und Nutzer die Website nicht mehr erreichen können.

Viele DNS-Provider automatisieren den Key Rollover mittlerweile vollständig, was das Risiko manueller Fehler erheblich reduziert. Unternehmen, die ihre DNS-Zonen selbst verwalten, sollten den Rollover-Prozess dokumentieren und regelmäßig testen.

Algorithmen und Schlüsselstärke

Die Sicherheit von DNSSEC hängt maßgeblich von den verwendeten kryptografischen Algorithmen ab. Ältere Verfahren wie RSA/SHA-1 (Algorithmus 5) gelten als unsicher und werden von der IETF ausdrücklich nicht mehr empfohlen. Das BSI empfiehlt in seinen technischen Richtlinien den Einsatz von ECDSAP256SHA256 (Algorithmus 13) oder ECDSAP384SHA384 (Algorithmus 14). Diese elliptischen Kurven bieten bei deutlich kürzeren Schlüsseln ein gleichwertiges oder höheres Sicherheitsniveau als RSA und erzeugen kompaktere Signaturen, was die Größe von DNS-Antworten reduziert.

Ed25519 (Algorithmus 15) ist ein weiterer moderner Algorithmus, der sich durch besonders hohe Performance und Sicherheit auszeichnet. Seine Verbreitung wächst, allerdings wird er noch nicht von allen DNS-Providern und Resolvern unterstützt. Für die meisten Unternehmen ist ECDSA P-256 derzeit die beste Kombination aus Sicherheit und Kompatibilität.

DNSSEC und E-Mail-Sicherheit

DNSSEC spielt eine wichtige, oft unterschätzte Rolle für die E-Mail-Authentifizierung. Die Protokolle SPF, DKIM und DMARC speichern ihre Konfiguration in DNS-TXT-Records. Wenn ein Angreifer DNS-Antworten manipulieren kann, kann er theoretisch auch SPF-Records fälschen und sich als autorisierter Absender ausgeben. DNSSEC schließt diese Lücke, indem es die Integrität aller DNS-Records — einschließlich der für die E-Mail-Authentifizierung relevanten TXT-Records — kryptografisch absichert.

Darüber hinaus ermöglicht DNSSEC den Einsatz von DANE (DNS-based Authentication of Named Entities), einem Verfahren, das TLS-Zertifikate über TLSA-Records im DNS verankert. DANE setzt eine funktionierende DNSSEC-Infrastruktur zwingend voraus und bietet eine Alternative oder Ergänzung zum klassischen CA-basierten Vertrauensmodell. Ob Ihre MX-Server DANE korrekt konfiguriert haben, zeigt der SMTP-TLS-Check. Ob die TLS-Konfiguration des Servers selbst — Protokollversionen, Cipher-Suites und Forward Secrecy — dem aktuellen Stand der Technik entspricht, lässt sich mit dem TLS-Cipher-Check prüfen. Für die E-Mail-Sicherheit ist DANE-TLSA besonders relevant, da es MTA-STS (Mail Transfer Agent Strict Transport Security) ergänzt und eine opportunistische TLS-Verschlüsselung zwischen Mailservern kryptografisch absichert.

Unternehmen, die bereits SPF, DKIM und DMARC korrekt konfiguriert haben, sollten DNSSEC als nächsten logischen Schritt in Betracht ziehen. Es bildet das Fundament, auf dem alle DNS-basierten Sicherheitsmechanismen aufbauen — ohne DNSSEC besteht immer die theoretische Möglichkeit, dass ein Angreifer die DNS-Ebene als Angriffsvektor nutzt.

Regulatorische Relevanz

Unter der NIS2-Richtlinie sind DNS-Dienste größenunabhängig als kritische Infrastruktur eingestuft. Unternehmen, die DNS-Dienste betreiben, müssen angemessene Sicherheitsmaßnahmen implementieren — DNSSEC gehört dabei zu den grundlegenden technischen Maßnahmen. Auch für Unternehmen, die keine eigenen DNS-Dienste betreiben, ist DNSSEC im Rahmen einer ganzheitlichen Sicherheitsstrategie relevant: Es schützt die Integrität der eigenen Domain und damit die Grundlage für Webauftritte, E-Mail-Kommunikation und digitale Geschäftsprozesse.

Das BSI empfiehlt in seinen Grundschutz-Katalogen die Aktivierung von DNSSEC für alle geschäftlich genutzten Domains. In der Praxis scheitert die Implementierung häufig daran, dass der DNS-Provider DNSSEC nicht unterstützt oder die Einrichtung als zu komplex empfunden wird. Tatsächlich bieten die meisten großen Registrare und DNS-Provider mittlerweile eine unkomplizierte DNSSEC-Aktivierung an — oft genügen wenige Klicks in der Verwaltungsoberfläche.

Verbreitung und Herausforderungen

Die DNSSEC-Verbreitung variiert stark nach Region und TLD. In den Niederlanden und Schweden liegt die Signierungsrate bei .nl- und .se-Domains vergleichsweise hoch, während in Deutschland nur ein Bruchteil der .de-Domains DNSSEC aktiviert hat. DENIC unterstützt DNSSEC seit 2011, doch die Aktivierung muss vom Domaininhaber über den Registrar angestoßen werden — eine automatische Aktivierung erfolgt nicht.

Einer der Gründe für die zögerliche Verbreitung ist die Angst vor Fehlkonfigurationen: Ein falsch konfiguriertes DNSSEC kann dazu führen, dass die gesamte Domain für Nutzer mit validierenden Resolvern nicht mehr erreichbar ist. Dieses Risiko lässt sich durch sorgfältige Planung, automatisierte Key-Rotation und regelmäßige Überprüfung mit Tools wie dem DNSSEC-Check minimieren. Unternehmen sollten nach der Aktivierung die Signaturvalidierung von verschiedenen Standorten und Resolvern aus testen, um sicherzustellen, dass die Konfiguration fehlerfrei ist.

DNSSEC aktivieren: typischer Ablauf

Die Aktivierung von DNSSEC erfolgt in der Regel in drei Schritten. Zunächst muss der DNS-Provider DNSSEC für die Zone aktivieren und die DNSKEY-Records generieren. Im zweiten Schritt wird der DS-Record bei der übergeordneten Zone — typischerweise über den Registrar — hinterlegt. Erst mit diesem Schritt wird die Vertrauenskette geschlossen und die DNSSEC-Validierung durch externe Resolver möglich. Im dritten Schritt sollte die Konfiguration mit einem DNSSEC-Validierungstool geprüft werden, um sicherzustellen, dass alle Records korrekt gesetzt und die Signaturen gültig sind.

Bei vielen modernen DNS-Providern wie Cloudflare, AWS Route 53 oder Hetzner ist der erste Schritt mit einem Klick erledigt. Die DS-Record-Hinterlegung beim Registrar erfordert je nach Anbieter einen manuellen Eintrag oder kann per API automatisiert werden. DENIC bietet für .de-Domains ein standardisiertes Verfahren zur DS-Übermittlung an.

Praxistipp

Ob Ihre Domain DNSSEC korrekt konfiguriert hat, können Sie mit dem kostenlosen DNSSEC-Check in wenigen Sekunden prüfen. Das Tool analysiert die vollständige Vertrauenskette — von den DS-Records über die DNSKEY-Schlüssel bis zu den RRSIG-Signaturen — und zeigt konkrete Handlungsempfehlungen. Ergänzend empfiehlt sich der DNS-Lookup, um die grundlegende DNS-Konfiguration zu prüfen, und der E-Mail Security Check, um sicherzustellen, dass auch SPF, DKIM und DMARC korrekt eingerichtet sind.