Comprendre la chaîne de confiance DNSSEC en 5 minutes
Par CaptainDNS
Publié le 22 février 2026
- 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
- 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 est la KSK racine. Elle est intégrée dans tous les résolveurs validants (1.1.1.1, 8.8.8.8, 9.9.9.9). C'est le fondement de toute la chaîne.
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.
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 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 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 possède déjà la KSK de la racine DNS (trust anchor). Cette clé est intégrée dans sa configuration. C'est le seul élément que le résolveur accepte sans vérification.
É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 vérifie la signature avec la KSK racine
- Le DS record de
.comest maintenant validé
Étape 3 : valider le TLD vers votre domaine
- Le résolveur demande le DS record de
captaindns.comau 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.comest 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.
Quand la chaîne se casse ?
En production, les ruptures de chaîne sont la première cause de SERVFAIL liés à DNSSEC. Trois scénarios reviennent systématiquement.
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.
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
Lancez un diagnostic DNSSEC complet de votre domaine pour vérifier que chaque maillon est en place.
Guides DNSSEC connexes
- Activer DNSSEC : guide pas-à-pas par registrar
- DANE/TLSA : le guide complet pour authentifier les certificats email par DNS
- SERVFAIL après activation DNSSEC : diagnostic et correction (à venir)
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é publique que le résolveur considère comme fiable sans vérification supplémentaire. En DNSSEC, le trust anchor est la KSK de la racine DNS. Elle est intégrée dans la configuration de tous les résolveurs validants.
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 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é publique considérée comme fiable par le résolveur sans vérification. En DNSSEC, la KSK de la racine DNS.
- 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.
