DNSSEC-Vertrauenskette: DS, DNSKEY, RRSIG und Fehlerfälle

Kurz gesagt. DNSSEC verknüpft Zonen über zwei Eintragstypen. Ein DS-Eintrag in der Elternzone enthält einen Hash des Key Signing Keys der Kindzone (DNSKEY, Flags 257). Dieser Schlüssel signiert das DNSKEY-RRset der Kindzone, und der Zone Signing Key (Flags 256) signiert die eigentlichen Einträge mit RRSIGs. Ein validierender Resolver beginnt beim Root-Schlüssel, dem er vertraut, und prüft jedes Glied bis hinunter zur Antwort. Scheitert ein Glied, liefert er SERVFAIL statt der Daten. Prüfe eine Kette mit delv („fully validated“) oder dig +dnssec (das Flag ad), vergleiche den DS der Elternzone mit dem DNSKEY der Kindzone mithilfe von dnssec-dsfromkey, und finde mit +cd heraus, ob die Daten zwar vorhanden sind, aber die Validierung nicht bestehen. Die meisten Ausfälle entstehen bei Key-Rollovers: ein DS, der nach einem KSK-Wechsel nicht aktualisiert wurde, Signaturen, die ohne Erneuerung ablaufen, oder Schlüssel, die schneller ausgetauscht werden, als die Einträge in den Caches ablaufen.

Die vier Eintragstypen

Der Aufbau trennt die Schlüssel nach Aufgaben. Der KSK signiert nur das DNSKEY-RRset, und sein Hash liegt in der Elternzone. Wer ihn wechselt, muss sich an die Elternzone wenden (Registrar oder Registry). Der ZSK signiert alles andere und lässt sich ohne Beteiligung der Elternzone wechseln. Eine Zone kann für beide Aufgaben auch einen einzigen kombinierten Schlüssel (CSK) verwenden; genau das tut die eingebaute dnssec-policy default von BIND (csk ... algorithm 13). Die Regeln sind dieselben, nur hat der Schlüssel die Flags 257 und signiert alles.

Eine echte Kette mit dig verfolgen

www.isc.org, Schritt für Schritt, am 20. Oktober 2026 (dig aus BIND 9.20.10, Abfragen an 1.1.1.1). Zuerst die Root-Zone. Deren DNSKEY-RRset enthält einen ZSK und zwei KSKs:

.			2158 IN	DNSKEY 256 3 8 (
) ; ZSK; alg = RSASHA256 ; key id = 8763
.			2158 IN	DNSKEY 257 3 8 (
) ; KSK; alg = RSASHA256 ; key id = 20326
.			2158 IN	DNSKEY 257 3 8 (
) ; KSK; alg = RSASHA256 ; key id = 38696

Schlüssel 20326 ist KSK-2017, 38696 ist KSK-2024. Der KSK-Rollover der Root-Zone fand neun Tage vor diesem Mitschnitt statt. In den Worten der ICANN: „Am 11. Oktober 2026 um 14:00 UTC hat KSK-2024 wie geplant begonnen, die DNS-Root-Zone zu signieren.“ Die Signatur über das DNSKEY-RRset der Root-Zone bestätigt das:

.			1587 IN	RRSIG DNSKEY 8 0 172800 (
20261101000000 20261011000000 38696 .

Das ist die einzige RRSIG über dieses RRset. Der alte Schlüssel bleibt bis zu seinem geplanten Widerruf veröffentlicht, signiert aber nicht mehr. Ein Resolver, der nur KSK-2017 vertraut, weil er KSK-2024 weder über die automatischen Aktualisierungen nach RFC 5011 noch durch ein Software-Update kennengelernt hat, kann nichts mehr validieren.

Dann jede Delegation. Der DS der Elternzone benennt den KSK der Kindzone über dessen Key-Tag:

org.			81000	IN	DS	26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
) ; ZSK; alg = RSASHA256 ; key id = 25488
) ; ZSK; alg = RSASHA256 ; key id = 11859
) ; ZSK; alg = RSASHA256 ; key id = 24060
) ; KSK; alg = RSASHA256 ; key id = 725
) ; KSK; alg = RSASHA256 ; key id = 26974
isc.org.		3600	IN	DS	7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 27566
) ; KSK; alg = ECDSAP256SHA256 ; key id = 7250

Der DS der Root-Zone für org. verweist auf Schlüssel 26974, den org. als KSK veröffentlicht. Der DS für isc.org. in org. verweist auf Schlüssel 7250, den KSK von isc.org. Beachte den Wechsel des Algorithmus auf dem Weg nach unten: org. signiert mit RSA (Algorithmus 8), isc.org mit ECDSA P-256 (Algorithmus 13). Jede Zone wählt ihren eigenen. Zum Schluss die Antwort und ihre Signatur durch den ZSK von isc.org, 27566:

www.isc.org.		300 IN A 151.101.3.42
www.isc.org.		300 IN A 151.101.67.42
www.isc.org.		300 IN A 151.101.131.42
www.isc.org.		300 IN A 151.101.195.42
www.isc.org.		300 IN RRSIG A 13 3 300 (
				20261103074926 20261020065242 27566 isc.org.
				qz5Qb4BFyOw4PRXBJjeK61LrPSKo6G2Ma1aFwNwZ57x5
				bFIg/d3EoMHtXopLYU949QQtMjcQ8BWULk7a629tLA== )

Die Felder der RRSIG: abgedeckter Typ A, Algorithmus 13, 3 Labels, ursprüngliche TTL 300, Ablaufzeitpunkt 2026-11-03 07:49:26 UTC, Gültigkeitsbeginn 2026-10-20 06:52:42 UTC, Key-Tag 27566, Signierer isc.org.. Ein validierender Resolver, der all das prüft, setzt das Flag AD (authentifizierte Daten):

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

ad ist die Aussage des Resolvers und nur so vertrauenswürdig wie der Weg zum Resolver. Um selbst zu validieren, nimm delv: Es geht den ganzen Weg lokal ab und prüft gegen seine eingebauten Root-Vertrauensanker. +rtrace zeigt die Abrufe:

;; fetch: www.isc.org/A
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: org/DS
;; fetch: ./DNSKEY
; fully validated

dig +sigchase, das ältere Anleitungen empfehlen, gibt es nicht mehr: dig 9.20 antwortet mit dig: +sigchase option no longer supported. Nimm delv. Für denselben Weg im Browser über DNS-over-HTTPS ruft der DNSSEC-Inspektor jedes Glied ab, prüft jede RRSIG mit eigenem Code und zeigt auf das Glied, das bricht.

Algorithmen 8, 13 und 15

Die Algorithmusnummer steht in DNSKEY-, DS- und RRSIG-Einträgen. RFC 9904 (November 2025) hat RFC 8624 abgelöst und die Empfehlungen direkt in die IANA-Registry verlagert; RFC 9905 erschien zeitgleich und verbietet das Signieren mit den beiden SHA-1-Algorithmen:

Für DS-Digests ist SHA-256 (Typ 2) die richtige Wahl. SHA-1 (Typ 1) ist für Delegationen „MUST NOT“, Validatoren müssen es aber weiterhin unterstützen. Von den zehn Zonen, die wir am 20. Oktober 2026 geprüft haben, signieren com., net., nl., cloudflare.com, isc.org, ietf.org, nic.cz und sidn.nl mit 13, org. und de. dagegen mit 8, ebenso wie die Root-Zone. Dieselbe Zone, mit jedem der drei Algorithmen signiert, zeigt, warum 13 so verbreitet ist:

algorithm 8  RSASHA256         ZSK public key 260 bytes, RRSIG signature 256 bytes
algorithm 13 ECDSAP256SHA256   ZSK public key  64 bytes, RRSIG signature  64 bytes
algorithm 15 ED25519           ZSK public key  32 bytes, RRSIG signature  64 bytes

Kleine Signaturen halten Antworten unter der UDP-Größengrenze (1232 Byte ist heute der übliche EDNS-Puffer). Das vermeidet Fragmentierung und den Rückfall auf TCP. Algorithmus 15 hat die kleinsten Schlüssel, aber die Unterstützung in Validatoren ist nur RECOMMENDED, nicht MUST. Prüfe also die Resolver deiner Zielgruppe, bevor du ihn wählst.

Eine Kette absichtlich unterbrechen

Um Fehler zu sehen, ohne eine echte Domain zu beschädigen, betreibt das folgende Labor zwei Instanzen von BIND 9.20.29 auf Debian 13. Die eine ist ein autoritativer Server für eine private Root-Zone ., für lab. und für shop.lab., alle mit Algorithmus 13 signiert. Die andere ist ein validierender Resolver, dessen einziger Vertrauensanker der DS dieser privaten Root-Zone ist. Schlüssel und Signaturen erzeugen die üblichen BIND-Tools:

keygen() { dnssec-keygen -q -K keys -a ECDSAP256SHA256 -L 3600 "$@"; }
for z in . lab shop.lab; do keygen -fKSK "$z" >/dev/null; keygen "$z" >/dev/null; done

# the parent includes the child's dsset file before signing
cat auth/db.lab.unsigned auth/dsset-shop.lab. > auth/db.lab
dnssec-signzone -q -S -K keys -d auth -o lab -f auth/db.lab.signed auth/db.lab

read -r _ _ _ tag alg dt d1 d2 < auth/dsset-.
echo "trust-anchors { . static-ds $tag $alg $dt \"$d1$d2\"; };" > anchors.conf

1. Alles korrekt. Der DS in lab. benennt den KSK von shop.lab., der Resolver setzt ad, und delv validiert:

DS in lab.: shop.lab. 48794 13 2
DNSKEY in shop.lab.: ZSK; alg = ECDSAP256SHA256 ; key id = 6251
DNSKEY in shop.lab.: KSK; alg = ECDSAP256SHA256 ; key id = 48794
$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.shop.lab.		5	IN	A	192.0.2.10
$ delv @127.0.0.2 -a anchors.conf www.shop.lab A
; fully validated
www.shop.lab.		5	IN	A	192.0.2.10

2. KSK in der Kindzone ersetzt, DS in der Elternzone nicht aktualisiert. Das ist der klassische Ausfall nach einem Umzug des DNS-Hostings oder nach einem automatisierten KSK-Rollover, den niemand beim Registrar abgeschlossen hat:

DS in lab.: shop.lab. 48794 13 2
DNSKEY in shop.lab.: KSK; alg = ECDSAP256SHA256 ; key id = 11943
DNSKEY in shop.lab.: ZSK; alg = ECDSAP256SHA256 ; key id = 6251
$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
$ dig @127.0.0.1 www.shop.lab A +dnssec +cd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.shop.lab.		5	IN	A	192.0.2.10
$ delv @127.0.0.2 -a anchors.conf www.shop.lab A
;; validating shop.lab/DNSKEY: no valid signature found (DS)
;; broken trust chain resolving 'www.shop.lab/A/IN': 127.0.0.2#53
;; resolution failed: broken trust chain

Der DS nennt weiterhin 48794, die Zone hat jetzt aber KSK 11943. +cd (Prüfung deaktiviert) liefert die Daten. Das beweist, dass die Zone erreichbar ist und nur die Validierung scheitert. So unterscheidest du am schnellsten einen DNSSEC-Fehler von einem Ausfall.

3. Signaturen abgelaufen. Der DS ist korrigiert, aber die Zone wurde einmal signiert und nie neu signiert. Hier signiert das Labor sie mit einem Gültigkeitsbeginn vor zehn Tagen und einem Ablaufzeitpunkt vor einer Stunde:

RRSIG inception 20261010131152 expiration 20261020121152
$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDE: 7 (Signature Expired): (shop.lab/DNSKEY)
$ delv @127.0.0.2 -a anchors.conf www.shop.lab A
;; validating shop.lab/DNSKEY: no valid signature found (DS)
;; broken trust chain resolving 'www.shop.lab/A/IN': 127.0.0.2#53
;; resolution failed: broken trust chain

BIND hängt einen Extended DNS Error (RFC 8914) an, der die Ursache nennt: EDE: 7 (Signature Expired). Statisches Signieren mit dnssec-signzone erzeugt standardmäßig 30-Tage-Signaturen (die erste Signierung im Labor ergab Beginn 20261020120639, Ablauf 20261119120639). Ein Cronjob, der nicht mehr neu signiert, verursacht also genau das einen Monat später. Lass stattdessen den DNS-Server automatisch signieren und neu signieren: mit dnssec-policy in BIND, dessen Standard 14-Tage-Signaturen alle 5 Tage erneuert, oder dem Gegenstück in Knot oder PowerDNS.

4. ZSK in einem Schritt getauscht. Die Zone ersetzt ihren ZSK und signiert sofort alles mit dem neuen Schlüssel neu. Ein Resolver, der das alte DNSKEY-RRset zwischengespeichert hat (TTL 3600), bekommt einen A-Eintrag, der mit einem Schlüssel signiert ist, den er nicht hat:

$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.shop.lab.		5	IN	A	192.0.2.10
resolver cache: DNSKEY flags 256 TTL 3600
resolver cache: DNSKEY flags 257 TTL 3600
(6 s later: the A record's 5 s TTL has expired, the cached DNSKEY set's 3600 s TTL has not)
$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
(resolver restarted, cache empty)
$ dig @127.0.0.1 www.shop.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.shop.lab.		5	IN	A	192.0.2.10

Die Zone selbst ist gültig: Ein frischer Resolver validiert sie. Aber jeder Resolver, der den alten Schlüsselsatz zwischengespeichert hat, scheitert, bis dieser Cache-Eintrag abläuft. Der Ausfall tritt sporadisch und je nach Resolver auf – die Art von Fehler, die sich am schwersten debuggen lässt.

Key-Rollover ohne Ausfall

RFC 6781 beschreibt die sicheren Abfolgen. Allen liegt dieselbe Regel zugrunde: Jeder Resolver muss mit jeder Mischung aus alten und neuen Einträgen validieren können, die er gerade im Cache hat.

• ZSK, Pre-Publish. Nimm den neuen ZSK in das DNSKEY-RRset auf, während der alte noch signiert. Warte mindestens die TTL des DNSKEY-RRsets ab, damit jeder Cache beide Schlüssel hat. Stelle das Signieren auf den neuen Schlüssel um. Warte die längste TTL der signierten Daten ab, damit die alten Signaturen aus den Caches verschwinden. Entferne dann den alten Schlüssel.
• KSK, Doppelsignatur. Nimm den neuen KSK auf und signiere das DNSKEY-RRset mit beiden. Reiche den neuen DS bei der Elternzone ein. Warte, bis die Elternzone ihn veröffentlicht und der alte DS aus den Caches abgelaufen ist (TTL des DS, oft eine Stunde oder ein Tag). Entferne erst dann den alten KSK.
• Algorithmus-Rollover (zum Beispiel von 8 auf 13). Neue Schlüssel des neuen Algorithmus müssen alles signieren, bevor der neue DS erscheint, und der alte Algorithmus muss weiter signieren, bis der alte DS verschwunden ist. Die vollständige Abfolge steht in RFC 6781 § 4.1.4.
• Automatisiere den Schritt bei der Elternzone. Mit CDS- und CDNSKEY-Einträgen (RFC 8078) kann eine Elternzone, die sie unterstützt, den neuen DS selbst aus der Kindzone übernehmen. Ohne sie ist der DS-Schritt Handarbeit beim Registrar, und genau dort bleiben Rollovers stecken.
• DNS-Anbieter wechseln. Wechsle entweder koordiniert im Multi-Signer-Verfahren, oder entferne zuerst den DS beim Registrar, warte seine TTL ab und aktiviere DNSSEC mit dem Schlüssel des neuen Anbieters wieder. Die NS-Einträge umzustellen, während der alte DS bestehen bleibt, ist Fall 2 im Produktivbetrieb.

dnssec-policy in BIND und die Schlüsselverwaltung in Knot und PowerDNS halten diese Wartezeiten für dich ein. Der typische Fehler liegt nicht im Tool, sondern im Schritt bei der Elternzone: ein DS, der in ein Webformular des Registrars eingefügt werden muss.

SERVFAIL diagnostizieren

1. Liegt es an DNSSEC? dig name +cd liefert Daten, während dig name SERVFAIL ergibt → Validierungsfehler. Suche nach einer Zeile EDE: 6 (DNSSEC Bogus), 7 (Signature Expired), 8 (Signature Not Yet Valid), 9 (DNSKEY Missing), 10 (RRSIGs Missing).
2. Welches Glied? Führe delv name +rtrace aus und lies den ersten fehlschlagenden Schritt.
3. DS gegen DNSKEY: Berechne den DS aus den Schlüsseln der Kindzone und vergleiche ihn mit der Elternzone:

$ dig +short DS isc.org @1.1.1.1
7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
$ dig +cd +noall +answer DNSKEY isc.org @1.1.1.1 | dnssec-dsfromkey -2 -f - isc.org
isc.org. IN DS 7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697CDA01CB2
$ dig +short DS dnssec-failed.org @1.1.1.1
42069 13 2 62726F6B656E20636861696E206F662074727573742073656E642068 656C7021
$ dig +cd +noall +answer DNSKEY dnssec-failed.org @1.1.1.1 | dnssec-dsfromkey -2 -f - dnssec-failed.org
dnssec-failed.org. IN DS 50719 13 2 D602C971A02AF89B7661B99D6DD1B9E2EC876617631D04F633902A42CD4D6BBD

isc.org stimmt überein. dnssec-failed.org ist eine absichtlich defekte Testdomain auf den Nameservern von Comcast (dns101.comcast.net und weitere). Der DS dieser Domain benennt Schlüssel 42069, den es nicht gibt, und der Digest ist ASCII für „broken chain of trust send help!“. Öffentliche Resolver lehnen sie entsprechend ab:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59477
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

1. Signaturzeiten: Vergleiche Gültigkeitsbeginn und Ablaufzeitpunkt der RRSIG mit der aktuellen UTC-Zeit. Ein Signierer oder Validator mit falsch gehender Uhr führt zu „noch nicht gültig“ oder „abgelaufen“.
2. Resolverabhängige Fehler nach einem Schlüsselwechsel deuten auf Caching hin (Fall 4). Prüfe die TTLs der DNSKEY- und DS-RRsets und den Zeitpunkt des Wechsels.

Was DNSSEC möglich macht

Eine funktionierende Vertrauenskette ist die Grundlage für Einträge, die Authentizität brauchen, nicht nur Verfügbarkeit. DANE/TLSA pinnt TLS-Schlüssel im DNS und wird für SMTP zwischen Mailservern verwendet. Der TLSA-Eintragsgenerator erstellt solche Einträge. CAA-Einträge werden von CAs geprüft, und seit dem 15. März 2026 verlangen die Baseline Requirements des CA/Browser Forums eine DNSSEC-Validierung der CAA-Abfragen, wenn die Zone signiert ist. Eine defekte Kette kann deshalb auch die Ausstellung von Zertifikaten blockieren.

Quellen

• RFC 4033, RFC 4034, RFC 4035: Einführung in DNSSEC, Eintragstypen, Protokoll.
• RFC 9904: Verfahren zur Aktualisierung der Empfehlungen für DNSSEC-Algorithmen (November 2025).
• RFC 9905: Abkündigung von SHA-1 in DNSSEC-Signaturalgorithmen (November 2025).
• RFC 6781: DNSSEC im Betrieb, Key-Rollovers. RFC 8078: CDS/CDNSKEY.
• RFC 8914: Extended DNS Errors.
• ICANN, KSK-Rollover der Root-Zone.

Die Abfragen an echte Zonen liefen am 20. Oktober 2026 in nicolaka/netshoot:v0.14 (dig und delv aus BIND 9.20.10). Das Labor und dnssec-dsfromkey liefen in debian:trixie-20261005-slim mit BIND 9.20.29 aus Debian.