Chaîne de confiance DNSSEC : DS, DNSKEY, RRSIG et pannes

En bref. DNSSEC relie les zones par deux types d’enregistrements. Un enregistrement DS dans la zone parente contient un condensat de la clé de signature de clé de la zone enfant (DNSKEY, indicateurs 257). Cette clé signe l’ensemble DNSKEY de la zone enfant, et la clé de signature de zone (indicateurs 256) signe les enregistrements eux-mêmes avec des RRSIG. Un résolveur validant part de la clé racine à laquelle il fait confiance et vérifie chaque maillon jusqu’à la réponse. Si un maillon échoue, il renvoie SERVFAIL au lieu des données. Vérifiez une chaîne avec delv (« fully validated ») ou dig +dnssec (le bit ad), comparez le DS de la zone parente avec la DNSKEY de la zone enfant à l’aide de dnssec-dsfromkey, et utilisez +cd pour voir si les données sont présentes mais ne passent pas la validation. La plupart des pannes viennent des roulements de clés : un DS non mis à jour après un changement de KSK, des signatures qu’on a laissées expirer, ou des clés remplacées plus vite que les caches n’expirent.

Les quatre enregistrements

La conception répartit les clés par rôle. La KSK ne signe que le RRset DNSKEY, et son condensat se trouve dans la zone parente. La changer suppose de passer par la zone parente (bureau d’enregistrement ou registre). La ZSK signe tout le reste et peut être changée sans impliquer la zone parente. Une zone peut aussi utiliser une seule clé combinée (CSK) pour les deux rôles : c’est ce que fait default, la politique dnssec-policy intégrée à BIND (csk ... algorithm 13). Les règles sont les mêmes ; la clé a simplement les indicateurs 257 et signe tout.

Parcourir une vraie chaîne avec dig

www.isc.org, étape par étape, le 20 octobre 2026 (dig de BIND 9.20.10, requêtes envoyées à 1.1.1.1). D’abord la racine. Son ensemble DNSKEY contient une ZSK et deux KSK :

.			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

La clé 20326 est la KSK-2017 et la 38696 la KSK-2024. Le roulement de la KSK racine a eu lieu neuf jours avant cette capture. Selon les termes de l’ICANN, « le 11 octobre 2026 à 14 h 00 UTC, la KSK-2024 a commencé à signer la zone racine du DNS comme prévu ». La signature de l’ensemble DNSKEY de la racine le confirme :

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

C’est le seul RRSIG qui porte sur cet ensemble. L’ancienne clé reste publiée jusqu’à sa révocation prévue, mais elle ne signe plus. Un résolveur qui ne fait confiance qu’à la KSK-2017, parce qu’il n’a jamais appris la KSK-2024 par les mises à jour automatiques de la RFC 5011 ni par une mise à jour logicielle, ne peut plus rien valider.

Ensuite, chaque délégation. Le DS de la zone parente désigne la KSK de la zone enfant par son 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

Le DS de org. dans la racine pointe vers la clé 26974, que org. publie comme KSK. Le DS de isc.org. dans org. pointe vers la clé 7250, la KSK de isc.org. Notez le changement d’algorithme en descendant : org. signe avec RSA (algorithme 8), isc.org avec ECDSA P-256 (algorithme 13). Chaque zone choisit le sien. Enfin, la réponse et sa signature par la ZSK de 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== )

Les champs du RRSIG sont les suivants : type couvert A, algorithme 13, 3 labels, TTL d’origine 300, expiration 2026-11-03 07:49:26 UTC, début de validité 2026-10-20 06:52:42 UTC, key tag 27566, signataire isc.org.. Un résolveur validant qui vérifie tout cela positionne le bit AD (authenticated data, données authentifiées) :

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

ad est une affirmation du résolveur, et elle ne vaut que ce que vaut le chemin qui mène à ce résolveur. Pour valider vous-même, utilisez delv, qui effectue tout le parcours en local à partir de ses ancres de confiance racine intégrées. +rtrace affiche les requêtes émises :

;; 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, que recommandent d’anciens guides, a disparu : dig 9.20 répond dig: +sigchase option no longer supported. Utilisez delv. Pour effectuer le même parcours dans le navigateur via DNS-over-HTTPS, l’inspecteur DNSSEC récupère chaque maillon, vérifie chaque RRSIG avec son propre code et désigne le maillon qui casse.

Algorithmes 8, 13 et 15

Le numéro d’algorithme figure dans les enregistrements DNSKEY, DS et RRSIG. La RFC 9904 (novembre 2025) a remplacé la RFC 8624 et a transféré les recommandations dans le registre IANA lui-même ; la RFC 9905, publiée en même temps, interdit de signer avec les deux algorithmes SHA-1 :

Pour les condensats DS, c’est SHA-256 (type 2) qu’il faut utiliser. SHA-1 (type 1) est classé « NE DOIT PAS » pour les délégations, même si les validateurs doivent encore le prendre en charge. Sur les dix zones que nous avons vérifiées le 20 octobre 2026, com., net., nl., cloudflare.com, isc.org, ietf.org, nic.cz et sidn.nl signent avec l’algorithme 13, tandis que org. et de. utilisent le 8, tout comme la racine. Signer la même zone avec chaque algorithme montre pourquoi le 13 est si répandu :

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

Des signatures courtes maintiennent les réponses sous la limite de taille UDP (la taille de tampon EDNS courante est aujourd’hui de 1232 octets), ce qui évite la fragmentation et le repli sur TCP. L’algorithme 15 a les clés les plus petites, mais sa prise en charge n’est que RECOMMANDÉE pour les validateurs, et non obligatoire (DOIT) : vérifiez donc les résolveurs de votre audience avant de le choisir.

Casser une chaîne volontairement

Pour observer les échecs sans casser un vrai domaine, le laboratoire ci-dessous fait tourner deux instances de BIND 9.20.29 sur Debian 13. L’une est un serveur faisant autorité pour une racine privée ., pour lab. et pour shop.lab., trois zones signées avec l’algorithme 13. L’autre est un résolveur validant dont la seule ancre de confiance est le DS de cette racine privée. La génération des clés et la signature reposent sur les outils BIND habituels :

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. Tout est correct. Le DS dans lab. désigne la KSK de shop.lab., le résolveur positionne ad, et delv valide :

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 remplacée dans la zone enfant, DS de la zone parente non mis à jour. C’est la panne classique après un changement d’hébergeur DNS ou un roulement automatique de KSK que personne n’a mené à terme auprès du bureau d’enregistrement :

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

Le DS indique toujours 48794, alors que la zone a désormais la KSK 11943. +cd (checking disabled, vérification désactivée) renvoie les données, ce qui prouve que la zone répond et que seule la validation échoue. C’est le moyen le plus rapide de distinguer un échec DNSSEC d’une panne.

3. Signatures expirées. Le DS est corrigé, mais la zone a été signée une fois et jamais re-signée. Ici, le laboratoire la signe avec un début de validité il y a dix jours et une expiration il y a une heure :

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 joint une erreur DNS étendue (Extended DNS Error, RFC 8914) qui nomme la cause : EDE: 7 (Signature Expired). La signature statique avec dnssec-signzone produit par défaut des signatures valables 30 jours (la première signature du laboratoire a donné un début de validité 20261020120639 et une expiration 20261119120639) : une tâche cron qui a cessé de re-signer provoque donc exactement cette panne un mois plus tard. Laissez plutôt le serveur DNS signer et re-signer automatiquement : dnssec-policy dans BIND, dont la configuration par défaut renouvelle des signatures de 14 jours tous les 5 jours, ou l’équivalent dans Knot ou PowerDNS.

4. ZSK remplacée en une seule étape. La zone remplace sa ZSK et re-signe immédiatement tout son contenu avec la nouvelle clé. Un résolveur qui a mis en cache l’ancien ensemble DNSKEY (TTL 3600) reçoit un enregistrement A signé par une clé qu’il ne possède pas :

$ 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

La zone elle-même est valide : elle est validée par un résolveur au cache vide. Mais chaque résolveur qui a mis en cache l’ancien ensemble de clés échoue jusqu’à l’expiration de cette entrée de cache. La panne est intermittente et dépend du résolveur : c’est le type de panne le plus difficile à déboguer.

Des roulements de clés sans panne

La RFC 6781 décrit les séquences sans risque. Toutes reposent sur une même règle : chaque résolveur doit pouvoir valider avec n’importe quel mélange d’anciens et de nouveaux enregistrements présents dans son cache.

• ZSK, prépublication. Ajoutez la nouvelle ZSK à l’ensemble DNSKEY pendant que l’ancienne signe encore. Attendez au moins le TTL des DNSKEY, pour que chaque cache contienne les deux clés. Basculez la signature sur la nouvelle clé. Attendez le plus long TTL des données signées, le temps que les anciennes signatures disparaissent des caches. Retirez ensuite l’ancienne clé.
• KSK, double signature. Ajoutez la nouvelle KSK et signez l’ensemble DNSKEY avec les deux. Soumettez le nouveau DS à la zone parente. Attendez que la zone parente le publie et que l’ancien DS ait expiré dans les caches (TTL du DS, souvent une heure ou un jour). Ne retirez l’ancienne KSK qu’à ce moment-là.
• Roulement d’algorithme (par exemple de 8 à 13). Les nouvelles clés du nouvel algorithme doivent tout signer avant l’apparition du nouveau DS, et l’ancien algorithme doit continuer à signer jusqu’à la disparition de l’ancien DS. La RFC 6781 §4.1.4 donne la séquence complète.
• Automatisez le côté parent. Les enregistrements CDS et CDNSKEY (RFC 8078) permettent à une zone parente qui les prend en charge de récupérer le nouveau DS auprès de la zone enfant. Sans cela, l’étape du DS se fait à la main auprès du bureau d’enregistrement, et c’est là que les roulements restent bloqués.
• Changement de fournisseur DNS. Soit vous effectuez une migration multi-signataire coordonnée, soit vous supprimez d’abord le DS auprès du bureau d’enregistrement, attendez son TTL et réactivez DNSSEC avec la clé du nouveau fournisseur. Déplacer les enregistrements NS tant que l’ancien DS reste en place, c’est le cas 2 en production.

La dnssec-policy de BIND et les gestionnaires de clés de Knot et de PowerDNS appliquent ces délais à votre place. L’échec courant ne vient pas de l’outil, mais de l’étape côté parent : un DS qu’il faut coller dans le formulaire web d’un bureau d’enregistrement.

Diagnostiquer un SERVFAIL

1. Est-ce DNSSEC ? dig name +cd renvoie des données alors que dig name donne SERVFAIL → échec de validation. Cherchez une ligne EDE : 6 (DNSSEC Bogus), 7 (Signature Expired), 8 (Signature Not Yet Valid), 9 (DNSKEY Missing), 10 (RRSIGs Missing).
2. Quel maillon ? Lancez delv name +rtrace et lisez la première étape en échec.
3. DS contre DNSKEY : calculez le DS à partir des clés de la zone enfant et comparez-le avec celui de la zone parente :

$ 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

Pour isc.org, les deux correspondent. dnssec-failed.org est un domaine de test volontairement cassé, servi par les serveurs de noms de Comcast (dns101.comcast.net et d’autres). Son DS désigne la clé 42069, qui n’existe pas, et le condensat est le texte ASCII « broken chain of trust send help! ». Les résolveurs publics le rejettent donc :

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

1. Dates de validité des signatures : comparez le début de validité et l’expiration du RRSIG avec l’heure UTC actuelle. Un signataire ou un validateur dont l’horloge est fausse produit des erreurs « pas encore valide » ou « expirée ».
2. Des échecs qui dépendent du résolveur après un changement de clé mettent en cause le cache (cas 4). Vérifiez les TTL des ensembles DNSKEY et DS ainsi que l’heure du changement.

Ce que DNSSEC rend possible

Une chaîne de confiance qui fonctionne est le socle des enregistrements qui exigent l’authenticité, et pas seulement la disponibilité. DANE/TLSA épingle des clés TLS dans le DNS et est utilisé pour SMTP entre serveurs de messagerie. Le générateur d’enregistrements TLSA produit de tels enregistrements. Les enregistrements CAA sont vérifiés par les autorités de certification et, depuis le 15 mars 2026, les Baseline Requirements du CA/Browser Forum exigent la validation DNSSEC des requêtes CAA lorsque la zone est signée. Une chaîne rompue peut donc aussi bloquer l’émission de certificats.

Sources

• RFC 4033, RFC 4034, RFC 4035 : introduction à DNSSEC, enregistrements, protocole.
• RFC 9904 : processus de mise à jour des recommandations d’algorithmes DNSSEC (novembre 2025).
• RFC 9905 : abandon de SHA-1 dans les algorithmes de signature DNSSEC (novembre 2025).
• RFC 6781 : pratiques opérationnelles DNSSEC, roulements de clés. RFC 8078 : CDS/CDNSKEY.
• RFC 8914 : erreurs DNS étendues (Extended DNS Errors).
• ICANN, Roulement de la KSK de la zone racine.

Les requêtes réelles ont été exécutées le 20 octobre 2026 dans nicolaka/netshoot:v0.14 (dig et delv de BIND 9.20.10). Le laboratoire et dnssec-dsfromkey ont tourné dans debian:trixie-20261005-slim avec le BIND 9.20.29 de Debian.