Netzwerk & WAN
DNSSEC
DNSSEC (DNS Security Extensions) signiert DNS-Daten kryptografisch und sichert so Echtheit und Integrität der Antworten, schützt aber nicht ihre Vertraulichkeit.
- Echtheit und Integrität von DNS
- Vertrauenskette bis zur Root
- DNSKEY, RRSIG, DS, NSEC/NSEC3
- KSK / ZSK / CSK
- Fundament für DANE
DNSSEC (DNS Security Extensions) erweitert DNS um digitale Signaturen. Ein validierender Resolver kann damit prüfen, dass eine Antwort wirklich vom zuständigen autoritativen Server stammt und unterwegs nicht verändert wurde. Was DNSSEC bewusst nicht leistet: Es verschlüsselt die Anfragen nicht, dafür sind DoT/DoH zuständig.
Dieser Artikel erklärt die Schlüsseltypen KSK und ZSK, die Records DNSKEY, RRSIG, DS und NSEC/NSEC3, die Vertrauenskette bis zur Root, die Validierung beim Resolver sowie die Grenzen und die Verbindung zu DANE.
1. Schlüssel und Records
Eine signierte Zone nutzt typischerweise zwei Schlüssel: Der ZSK (Zone Signing Key) signiert die eigentlichen Records, der KSK (Key Signing Key) signiert nur die Schlüssel und wird über einen DS-Record in der Elternzone verankert. Die Signaturen liegen als RRSIG vor, die öffentlichen Schlüssel als DNSKEY. Für die authentifizierte Auskunft „diesen Namen gibt es nicht“ dienen NSEC bzw. das gegen Zone-Enumeration gehärtete NSEC3.
2. Die Vertrauenskette
Die Validierung folgt der DNS-Hierarchie von oben nach unten: Der Resolver kennt den fest verankerten Root-Trust-Anchor. Die Root signiert den DS-Record der TLD, die TLD den DS-Record der Domäne, und die Domäne ihre eigenen Records. Schlägt irgendein Glied der Kette fehl, liefert ein validierender Resolver SERVFAIL statt der möglicherweise gefälschten Antwort.
DNSSEC verschiebt das Vertrauen vom Transportweg auf die Daten selbst: Egal über welchen Resolver eine signierte Antwort kommt, ihre Echtheit lässt sich kryptografisch bis zur Root zurückverfolgen.
3. NSEC gegen NSEC3
Um die Nichtexistenz eines Namens zu beweisen, verweist NSEC auf den nächsten existierenden Namen, was das Auslesen der ganzen Zone erlaubt (Zone Walking). NSEC3 hasht die Namen vorher und erschwert das. RFC 9276 empfiehlt für neue Zonen, den Iterationswert auf 0 und den Salt leer zu setzen, weil zusätzliche Iterationen nur Rechenlast erzeugen.
4. Grenzen
DNSSEC sichert die Daten, nicht ihre Bedeutung: Ein korrekt signierter Record kann trotzdem auf eine Schadseite zeigen. Vertraulichkeit bietet es nicht, und durch die größeren, signierten Antworten kann DNSSEC Amplification-Angriffe begünstigen, weshalb Response Rate Limiting wichtiger wird. Auf DNSSEC aufbauend bindet DANE (über TLSA-Records) TLS-Zertifikate direkt an Domänennamen, etwa zur Absicherung von SMTP.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Erkennt manipulierte und gefälschte DNS-Antworten zuverlässig | Schützt keine Vertraulichkeit (dafür DoT/DoH) |
| Globale Vertrauenskette bis zur Root, herstellerunabhängig | Schlüssel-Management und Rollover erfordern Disziplin/Automatisierung |
| Fundament für DANE (Zertifikatsbindung im DNS) | Größere Antworten können Amplification begünstigen |
Häufige Fragen zu DNSSEC
Nein. DNSSEC sichert Echtheit und Integrität der Antworten, verschlüsselt sie aber nicht. Wer das Mitlesen verhindern will, kombiniert DNSSEC mit DNS over TLS (DoT) oder DNS over HTTPS (DoH).
Der ZSK signiert die eigentlichen Zonendaten und wird häufiger rotiert. Der KSK signiert nur die Schlüssel und wird über einen DS-Record in der Elternzone verankert; er rotiert seltener. Manche Setups verwenden stattdessen einen kombinierten Schlüssel (CSK).
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
DNSSEC im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.