Chaîne de confiance DNSSEC : comprendre en 5 minutes (2026)

Q: Comment vérifier que DNSSEC fonctionne sur mon domaine ?

Exécutez dig captaindns.com +dnssec | grep flags . Si le flag ad (Authenticated Data) est présent, la chaîne de confiance est validée. Vous pouvez aussi utiliser un outil en ligne qui vérifie le DS record, les DNSKEY et les signatures RRSIG.

TL;DR

La chaîne de confiance DNSSEC relie la racine DNS à votre domaine via des signatures cryptographiques imbriquées
Trois types d'enregistrements assurent la validation : DNSKEY (clés publiques), RRSIG (signatures) et DS (lien vers la zone parente)
Chaque maillon vérifie le suivant : racine signe le TLD, le TLD signe votre domaine
Depuis le 11 octobre 2026, la KSK 38696 signe la racine DNS : un résolveur maison qui ne l'a pas dans ses ancres peut renvoyer des SERVFAIL
Vérifiez que votre chaîne est intacte avec notre DNSSEC Checker (voir plan d'action en fin d'article)

Vous activez DNSSEC, tout semble fonctionner, puis un matin vos visiteurs reçoivent SERVFAIL. Le coupable ? Un maillon cassé dans la chaîne de confiance.

Contrairement à un certificat TLS, DNSSEC est un système distribué. La confiance se propage de la racine DNS jusqu'à votre domaine, maillon par maillon. Un seul maillon défaillant et toute la chaîne s'effondre.

Ce guide vous explique chaque composant en 5 minutes : clés, signatures, validation et erreurs courantes.

Pourquoi le DNS a besoin d'une chaîne de confiance ?

Le DNS a été conçu en 1983 (RFC 1034) sans aucune authentification. Un attaquant pouvait injecter une fausse réponse (DNS spoofing) et rediriger le trafic vers un serveur malveillant.

DNSSEC (RFC 4033) ajoute des signatures cryptographiques pour résoudre ce problème. Mais une signature seule ne suffit pas. Il faut aussi vérifier que la clé de signature est légitime. C'est le rôle de la chaîne de confiance.

Le principe : chaque niveau de la hiérarchie DNS garantit l'authenticité du niveau suivant.

Les trois niveaux de la hiérarchie DNS

La résolution DNS suit une structure arborescente à trois niveaux. DNSSEC exploite cette hiérarchie pour construire la chaîne de confiance.

Niveau 1 : la racine DNS (root)

La racine DNS est le point de départ de toute résolution. Elle est gérée par l'IANA (Internet Assigned Numbers Authority) et distribuée sur 13 clusters de serveurs racine. La racine signe les enregistrements DS de chaque TLD.

L'ancre de confiance (trust anchor) de la racine s'appuie sur sa KSK. Le résolveur validant la conserve dans sa configuration et doit la maintenir à jour lors des changements de clé. C'est le point de départ de la chaîne, pas une clé intégrée une fois pour toutes.

Niveau 2 : le TLD (.com, .fr, .org)

Le TLD reçoit sa légitimité de la racine via un DS record. Le registre du TLD (Verisign pour .com, AFNIC pour .fr) gère la signature de sa zone. Le TLD signe à son tour les DS records de chaque domaine enregistré.

Niveau 3 : votre domaine (captaindns.com)

Votre domaine est le dernier maillon. Votre fournisseur DNS signe les enregistrements de votre zone (A, MX, TXT, etc.) et publie les clés publiques. Le DS record publié au TLD relie votre zone à la zone parente.

Chaîne de confiance DNSSEC : de la racine DNS au domaine, chaque niveau signe le suivant

Les clés cryptographiques : ZSK et KSK

Chaque zone DNSSEC utilise deux paires de clés. Leur séparation permet une rotation indépendante et limite l'impact d'une compromission.

ZSK (Zone Signing Key)

La ZSK signe les enregistrements DNS de votre zone. Chaque type d'enregistrement (A, MX, TXT, AAAA) reçoit sa propre signature RRSIG.

Taille typique : 1024-2048 bits (RSA) ou 256 bits (ECDSA P-256)
Rotation : tous les 1 à 3 mois
Publiée dans : l'enregistrement DNSKEY de votre zone (flag 256)

La rotation fréquente de la ZSK limite les risques. Si la clé est compromise, l'exposition est limitée dans le temps. La rotation de la ZSK ne nécessite pas de mise à jour du DS record au TLD.

KSK (Key Signing Key)

La KSK de votre domaine signe uniquement le jeu de DNSKEY (y compris la ZSK). Son hash est publié dans le DS record au niveau du TLD. C'est le pont entre votre zone et la zone parente.

Taille typique : 2048-4096 bits (RSA) ou 384 bits (ECDSA P-384)
Rotation : tous les 1 à 2 ans
Publiée dans : l'enregistrement DNSKEY de votre zone (flag 257)

La rotation de la KSK de votre domaine est plus délicate : elle nécessite de mettre à jour le DS record au registrar. Une mauvaise coordination casse la chaîne de confiance.

Les enregistrements DNSSEC expliqués

Quatre types d'enregistrements DNS assurent le fonctionnement de la chaîne.

DNSKEY : les clés publiques

L'enregistrement DNSKEY contient la clé publique utilisée pour vérifier les signatures. Votre zone publie au minimum deux DNSKEY : une pour la ZSK (flag 256) et une pour la KSK (flag 257).

dig DNSKEY captaindns.com +short

Le résolveur utilise ces clés pour vérifier les signatures RRSIG des enregistrements de votre zone.

RRSIG : les signatures

Chaque enregistrement DNS signé possède un RRSIG correspondant. Celui-ci contient la signature, l'algorithme utilisé, la période de validité et le Key Tag de la clé signataire.

dig A captaindns.com +dnssec

Le résolveur vérifie que la signature RRSIG correspond bien à l'enregistrement retourné et que la clé (DNSKEY) est valide.

DS : le lien avec la zone parente

Le DS record (Delegation Signer) est publié dans la zone parente (le TLD). Il contient un hash de la KSK de votre zone. Le résolveur compare ce hash avec la KSK publiée dans votre DNSKEY. Si les deux correspondent, vos clés sont légitimes.

dig DS captaindns.com +short

Le DS record est le maillon critique entre deux niveaux de la hiérarchie. Sans DS record, la chaîne est rompue et DNSSEC apparaît comme INSECURE.

NSEC/NSEC3 : la preuve d'inexistence

NSEC et NSEC3 prouvent de manière authentifiée qu'un enregistrement n'existe pas. Sans eux, un attaquant pourrait forger des réponses NXDOMAIN et détourner le trafic.

NSEC3 (RFC 5155) ajoute un hachage des noms pour éviter l'énumération de zone (zone walking).

Comment le résolveur valide une réponse ?

Que se passe-t-il concrètement quand un résolveur reçoit une requête pour captaindns.com ? Voici les 4 étapes de validation.

Étape 1 : récupérer l'ancre de confiance

Le résolveur part d'une ancre de confiance racine configurée localement. Cette confiance initiale ne vient pas d'une zone parente ; l'ancre doit ensuite être maintenue à jour, notamment via RFC 5011 lorsque ce mécanisme est pris en charge et fonctionne.

Mise à jour du 12 octobre 2026 : le rollover de la KSK racine a eu lieu le 11 octobre. La section sur le rollover racine, plus bas, indique ce qu'il change pour un résolveur maison.

Étape 2 : valider la racine vers le TLD

Le résolveur demande le DS record de .com à la racine
La racine renvoie le DS record et sa signature RRSIG
Le résolveur valide le jeu DNSKEY racine avec la KSK racine, puis la signature du DS avec la ZSK ainsi authentifiée
Le DS record de .com est maintenant validé

Étape 3 : valider le TLD vers votre domaine

Le résolveur demande le DS record de captaindns.com au TLD .com
Le TLD renvoie le DS record et sa signature RRSIG
Le résolveur vérifie la signature avec la DNSKEY du TLD (validée à l'étape 2)
Le DS record de captaindns.com est maintenant validé

Étape 4 : valider votre zone

Le résolveur demande le DNSKEY de captaindns.com
Il compare le hash de la KSK avec le DS record validé à l'étape 3
Si le hash correspond, les DNSKEY sont légitimes
Le résolveur demande l'enregistrement A et vérifie son RRSIG avec la ZSK

Si toutes les étapes réussissent, la réponse est marquée SECURE (flag ad dans la réponse DNS). Si une étape échoue ? La réponse est BOGUS et le résolveur renvoie SERVFAIL.

Processus de validation DNSSEC étape par étape : de la racine à l'enregistrement final

Rollover de la KSK racine : point au 12 octobre 2026

Depuis le 11 octobre 2026, KSK-2024 (key tag 38696) signe le jeu DNSKEY de la zone racine à la place de KSK-2017 (20326) : elle est la seule KSK à le signer. Constat du 12 octobre 2026 : sur k.root-servers.net et a.root-servers.net, le jeu DNSKEY racine est signé par 38696, et IANA classe KSK-2024 en statut Active, « Signing since 2026-10-11 ». Ce rollover ne change pas l'algorithme. Les DS des TLD restent signés par la ZSK.

Publiée le 11 janvier 2025, la nouvelle clé devait être reconnue comme ancre via RFC 5011 dès le 10 février 2025. Ce calendrier ne prouve pas que la mise à jour a réussi sur votre résolveur.

L'ancienne clé 20326 reste publiée dans la zone racine. Au 12 octobre 2026, IANA la classe en statut Post-Publication et indique qu'elle reste une ancre de confiance valide : ne la retirez pas vous-même de votre résolveur. Pour son retrait, consultez le calendrier IANA à jour.

La consigne ICANN est de vérifier, sans le supposer, que 38696 est une ancre de confiance utilisable localement. Voir cette clé dans une réponse DNS ne suffit pas.

Un résolveur maison qui n'a pas 38696 dans ses ancres ne valide plus le jeu DNSKEY racine. Les SERVFAIL apparaissent sur des domaines sains à mesure que le jeu DNSKEY racine en cache expire (TTL de 2 jours). Si une requête renvoie SERVFAIL sur ce résolveur mais obtient une réponse normale avec dig +cd (validation désactivée pour ce seul test), c'est la validation qui échoue : vérifiez l'ancre 38696 avant de toucher à la zone ou au registrar. Avec 1.1.1.1, 8.8.8.8 ou 9.9.9.9, vous n'avez rien à faire sur leur ancre.

Quand la chaîne se casse ?

Une rupture peut venir de la zone ou du résolveur qui la valide. Voici quatre scénarios.

DS record manquant ou incorrect

C'est le cas le plus fréquent. Le DS record au TLD ne correspond pas à la KSK publiée dans votre zone. Causes :

Le DS record n'a jamais été ajouté au registrar (la zone est signée mais la chaîne n'est pas établie)
La KSK a été renouvelée sans mettre à jour le DS record
Une erreur dans les valeurs du DS record (Key Tag, Algorithm, Digest)

Résultat : INSECURE si aucun DS record. BOGUS si le DS record existe mais ne correspond pas.

Signatures RRSIG expirées

Chaque RRSIG a une durée de validité (souvent 7 à 30 jours). Si les signatures ne sont pas renouvelées avant expiration, le résolveur les rejette.

Résultat : BOGUS sur tous les enregistrements dont la signature a expiré.

Prévention : les fournisseurs DNS managés (Cloudflare, Route 53, OVHcloud) renouvellent automatiquement les signatures. Le risque existe surtout avec BIND ou PowerDNS autogérés.

Algorithmes incompatibles

Si le DS record spécifie un algorithme différent de celui utilisé par la DNSKEY, la validation échoue.

Résultat : BOGUS.

Ancre racine périmée côté résolveur

Depuis le rollover du 11 octobre 2026, un résolveur maison qui ne fait pas confiance à 38696 peut renvoyer des SERVFAIL sur de nombreux domaines pourtant sains. Le défaut est dans son ancre racine, pas dans le DS de votre domaine. Vérifiez cette ancre avant de modifier la zone ou le registrar.

Vérifier votre chaîne de confiance

Votre DNSSEC est-il correctement configuré ? Vérifiez en quelques secondes :

dig captaindns.com +dnssec +short

Le flag ad (Authenticated Data) dans la réponse confirme que la chaîne complète est validée :

dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

Pour une analyse complète de chaque maillon, notre outil DNS Lookup détaille les enregistrements DNSKEY, DS et RRSIG de votre domaine.

Plan d'action recommandé

Comprendre votre configuration : identifiez qui gère la signature de zone (fournisseur DNS) et qui gère le DS record (registrar)
Vérifier la chaîne : confirmez que le DS record au TLD correspond à votre KSK avec dig DS captaindns.com +short
Monitorer les expirations : surveillez la validité des signatures RRSIG et planifiez les rotations de clés
Documenter la procédure : notez les étapes de rotation KSK pour votre registrar spécifique
Tester après chaque changement : vérifiez la propagation DNS après toute modification DNSSEC
Résolveur maison : vérifiez que 38696 est bien une ancre de confiance de votre résolveur ; si une requête renvoie SERVFAIL sur ce résolveur mais une réponse normale avec dig +cd, c'est la validation qui échoue ; si vous utilisez uniquement 1.1.1.1, 8.8.8.8 ou 9.9.9.9, vous n'avez aucune intervention à faire sur leur ancre

Lancez un diagnostic DNSSEC complet de votre domaine pour vérifier ses DS, DNSKEY et RRSIG. Le DNSSEC Checker ne teste pas l'ancre locale de votre résolveur.

Guides DNSSEC connexes

FAQ

Qu'est-ce que la chaîne de confiance DNSSEC ?

Chaque niveau de la hiérarchie DNS (racine, TLD, domaine) garantit l'authenticité du niveau suivant via des signatures cryptographiques. Le résolveur remonte cette chaîne depuis la KSK racine (ancre de confiance) jusqu'à votre domaine.

Qu'est-ce qu'un trust anchor ?

Un trust anchor (ancre de confiance) est une clé ou une référence de clé que le résolveur considère comme fiable pour démarrer la validation. Pour la racine DNS, elle repose sur la KSK racine et doit être maintenue à jour, notamment lors d'un rollover. RFC 5011 prévoit cette mise à jour automatique, dont il faut vérifier le bon fonctionnement.

Mon résolveur maison est-il concerné par le rollover de la KSK racine ?

Oui, s'il valide DNSSEC. Depuis le 11 octobre 2026, la KSK 38696 signe le jeu DNSKEY racine : un résolveur maison qui ne l'a pas dans ses ancres peut renvoyer des SERVFAIL sur des domaines sains. Vérifiez que 38696 est reconnue comme ancre de confiance, sans présumer que RFC 5011 a réussi. Avec 1.1.1.1, 8.8.8.8 ou 9.9.9.9, vous n'avez aucune intervention à faire sur leur ancre.

Quelle est la différence entre ZSK et KSK ?

La ZSK (Zone Signing Key) signe les enregistrements DNS de votre zone (A, MX, TXT). La KSK (Key Signing Key) signe uniquement les DNSKEY. Leur séparation permet de renouveler la ZSK fréquemment sans toucher au DS record du registrar.

Que se passe-t-il si la chaîne de confiance est cassée ?

Si un maillon de la chaîne est invalide (DS incorrect, signature expirée, clé incompatible), le résolveur marque la réponse comme BOGUS et renvoie SERVFAIL au client. Vos visiteurs ne peuvent plus accéder à votre site tant que le problème n'est pas corrigé.

Comment fonctionne DNSSEC ?

DNSSEC ajoute des signatures cryptographiques à chaque enregistrement DNS. Votre fournisseur DNS signe les enregistrements avec une clé privée (ZSK). Le résolveur vérifie les signatures avec la clé publique (DNSKEY). La légitimité des clés est garantie par un DS record publié au TLD, formant une chaîne de confiance jusqu'à la racine.

Comment vérifier que DNSSEC fonctionne sur mon domaine ?

Exécutez dig captaindns.com +dnssec | grep flags. Si le flag ad (Authenticated Data) est présent, la chaîne de confiance est validée. Vous pouvez aussi utiliser un outil en ligne qui vérifie le DS record, les DNSKEY et les signatures RRSIG.

Pourquoi la rotation de la KSK est-elle risquée ?

La rotation de la KSK de votre domaine nécessite de mettre à jour le DS record au registrar. Pendant la transition, les deux DS records (ancien et nouveau) doivent coexister. Une mauvaise coordination (ancien DS supprimé avant propagation du nouveau) casse la chaîne et provoque des SERVFAIL.

DNSSEC fonctionne-t-il avec tous les résolveurs ?

Non. Seuls les résolveurs validants vérifient les signatures DNSSEC. Les principaux résolveurs publics (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) valident DNSSEC. Certains résolveurs d'opérateurs ne le font pas. Selon l'APNIC, environ 38 % des requêtes DNS mondiales sont validées DNSSEC en 2026.

Glossaire

Trust anchor (ancre de confiance) : clé ou référence de clé reconnue comme fiable pour démarrer la validation DNSSEC ; l'ancre racine doit être maintenue à jour lors des changements de KSK.
DS record (Delegation Signer) : enregistrement publié dans la zone parente contenant un hash de la KSK. Lien entre deux niveaux de la hiérarchie.
DNSKEY : enregistrement contenant la clé publique de signature. Flag 256 pour la ZSK, flag 257 pour la KSK.
RRSIG : signature cryptographique d'un enregistrement DNS. Contient l'algorithme, la période de validité et le Key Tag.
NSEC/NSEC3 : enregistrements de preuve d'inexistence authentifiée. NSEC3 ajoute un hachage pour éviter l'énumération de zone.
BOGUS : état d'une réponse DNS dont la validation DNSSEC a échoué. Le résolveur renvoie SERVFAIL.