Was ist DNSSEC?
DNSSEC (Domain Name System Security Extensions) ergänzt DNS-RRsets um digitale Signaturen. Ein validierender Resolver kann gültige Signaturen und eine Vertrauenskette verwenden, um signierte Daten zu authentifizieren und unbefugte Änderungen zu erkennen. DNSSEC verschlüsselt DNS-Abfragen oder -Antworten nicht.Wie DNSSEC funktioniert
Vertrauenskette (Beispiel mit getrennten Schlüsseln):
Root-Zone (.)
├── Root-KSK (Trust Anchor) signiert das DNSKEY-RRset der Root-Zone
└── Root-ZSK signiert autoritative RRsets der Root-Zone, darunter das in der übergeordneten Root-Zone gespeicherte DS-RRset für .com
└── DS-Digest stimmt mit dem KSK von .com überein
├── .com-KSK signiert das DNSKEY-RRset von .com
└── .com-ZSK signiert autoritative RRsets von .com, darunter das in der übergeordneten .com-Zone gespeicherte DS-RRset für example.com
└── DS-Digest stimmt mit dem KSK von example.com überein
├── KSK von example.com signiert das DNSKEY-RRset von example.com
└── ZSK von example.com signiert autoritative RRsets von example.com
Resolver validiert Signaturen und DS-Digests ausgehend vom Trust Anchor der Root-Zone
DNSSEC-Eintragstypen
| Eintragstyp | Zweck | Beschreibung |
|---|---|---|
| RRSIG | Signatur | Kryptografische Signatur für jedes RRset |
| DNSKEY | Öffentlicher Schlüssel | Öffentliche Signaturschlüssel der Zone (KSK und ZSK) |
| DS | Delegation Signer | Hash des KSK der Kindzone in der Elternzone |
| NSEC/NSEC3 | Authentifizierte Nichtexistenz | Belegt, dass ein Eintrag nicht existiert |
Schlüsseltypen
| Schlüssel | Zweck | Rotationsfrequenz |
|---|---|---|
| KSK (Key Signing Key) | Signiert DNSKEY-RRsets | Abhängig von der Richtlinie; siehe Hinweis unten |
| ZSK (Zone Signing Key) | Signiert andere autoritative RRsets; NS- und Glue-RRsets der Delegation auf der Elternseite werden nicht signiert ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Abhängig von der Richtlinie; siehe Hinweis unten |
Der Zeitpunkt einer Rotation hängt von der Rolle des KSK und der Richtlinie des Betreibers ab. Für einen KSK, der durch einen DS-Eintrag in der übergeordneten Zone verknüpft ist, beschreibt [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) ein Jahr als angemessenen Zeitraum, wenn regelmäßige Rotationen vorgesehen sind. Ein als Trust Anchor verwendeter KSK muss mit den validierenden Resolvern abgestimmt werden und kann eine deutlich längere Wirksamkeitsdauer haben ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
Das Timing eines ZSK-Schlüsselwechsels hängt von den TTL-Werten der DNSKEYs und Signaturen, der Propagationszeit der Zonendaten und davon ab, wie lange mit dem auslaufenden ZSK erzeugte RRSIGs in Resolver-Caches verbleiben können ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)). Bei einem online gespeicherten ZSK mit vergleichsweise hoher Gefährdung durch Kompromittierung kann eine vorgesehene Lebensdauer von einem Monat angemessen sein ([RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3)); dies ist eine bedingte Orientierung, kein allgemeingültiges Rotationsintervall.
Root-KSK-Rollover am 11. Oktober 2026
ICANN nennt den 11. Oktober 2026 als Termin für den KSK-Rollover der Root Zone. Prüfen Sie, ob KSK-2024 (Key Tag 38696) in Ihrem validierenden Resolver als Trust Anchor geladen ist; automatische Aktualisierungen sind möglicherweise fehlgeschlagen. Fehlt der Schlüssel, prüfen Sie, ob automatische Aktualisierungen aktiviert sind, und befolgen Sie die Anweisungen Ihres Resolver-Herstellers. Aktuelle Einzelheiten finden Sie in den [ICANN-Hinweisen zum Root-KSK-Rollover](https://www.icann.org/resources/pages/ksk-rollover-en).
DNSSEC-Validierungsprozess
1. Der Client fragt den DNS-Resolver nach dem A-Eintrag für example.com.
2. Der Resolver ruft den A-Eintrag und die zugehörige RRSIG-Signatur ab.
3. Der Resolver ruft DNSKEY ab, um die RRSIG zu überprüfen.
4. Der Resolver validiert den DS-Eintrag anhand des DNSKEY-RRsets.
5. Die Vertrauenskette setzt sich bis zur Root-Zone fort; dabei wird jede Ebene überprüft.
6. Sind alle Signaturen gültig, ist die Antwort authentifiziert.
Was sich mit DNSSEC-Validierung erkennen lässt
Diese Prüfungen setzen signierte RRsets und einen validierenden Resolver mit intakter Vertrauenskette voraus. Nicht signierte oder unsichere Daten können nicht authentifiziert werden.
| Bedrohung | Beispiel | Schutz durch DNSSEC |
|---|---|---|
| Cache-Poisoning | Gefälschte DNS-Daten werden in den Cache eines Resolvers eingeschleust | Ein validierender Resolver kann Daten zurückweisen, wenn sich deren Signatur oder Vertrauenskette nicht validieren lässt. |
| Manipulation von Antworten | Ein signiertes DNS-RRset wird während der Übertragung verändert | Die veränderten Daten bestehen die Signaturprüfung nicht. |
| DNS-Spoofing | Für eine signierte Zone wird eine gefälschte Antwort geliefert | Ein validierender Resolver kann eine Antwort zurückweisen, die sich nicht validieren lässt. |
Überlegungen zur Implementierung
- Leistung: Größere Antworten aufgrund von Signaturen (~1000-4000 Bytes statt ~100 Bytes)
- Schlüsselverwaltung: Erfordert sichere Schlüsselerzeugung, Speicherung und Rotation
- Zonensignierung: Die Zone muss bei Änderungen an Einträgen erneut signiert werden
- Resolver-Unterstützung: Clients benötigen DNSSEC-validierende Resolver
Bewährte Vorgehensweisen
1. DNSSEC-Signaturalgorithmus auswählen: Das [IANA-Register für DNSSEC-Algorithmen](https://www.iana.org/assignments/dns-sec-alg-numbers) empfiehlt ECDSAP256SHA256 (Algorithmus 13) zum Signieren und Validieren. ECDSAP384SHA384 (14) kann für Anwendungen geeignet sein, die eine Sicherheitsstärke von 192 Bit benötigen; prüfen Sie vor einem Algorithmuswechsel die Unterstützung durch Resolver ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Schlüsselrotation automatisieren: Verwenden Sie Werkzeuge wie OpenDNSSEC für die Verwaltung des Schlüssellebenszyklus.
3. Gültigkeitsdauer überwachen: RRSIG-Signaturen haben eine Gültigkeitsdauer.
4. Vor der Bereitstellung testen: Validieren Sie die Zone mit Werkzeugen wie dnsviz.net.
5. Für Notfälle planen: Dokumentieren Sie Verfahren für den Schlüsselwechsel.
Wenn ein validierender Resolver die Vertrauenskette prüft, authentifiziert DNSSEC den Ursprung und die Integrität signierter DNS-Daten. DNSSEC bestätigt nicht, dass eine Website oder ein Server unter einer zurückgegebenen Adresse vertrauenswürdig ist.