DNSSEC Checker

Pourquoi vérifier DNSSEC ?

DNSSEC (DNS Security Extensions) ajoute une vérification cryptographique aux réponses DNS. Sans cette protection, un attaquant peut falsifier les réponses et rediriger votre trafic vers ses propres serveurs. C'est le principe du cache poisoning.

Le danger est silencieux. Un DS orphelin ou une rotation de clés incomplète fait disparaître un domaine. Aucun monitoring HTTP, aucun ping, aucun uptime check ne détectera ce problème. Ces pannes silencieuses persistent des jours. Les résolveurs validants (Google, Cloudflare, Quad9) renvoient SERVFAIL au lieu de la réponse attendue.

Quatre raisons de vérifier votre DNSSEC :

• Sécurité : Confirmer que la chaîne est intacte. Vos visiteurs atteignent vos serveurs, pas ceux d'un attaquant.
• Disponibilité : Un DNSSEC cassé bloque les résolveurs validants, soit environ un tiers à 40 % des requêtes mondiales selon les mesures APNIC. Google, Cloudflare et Quad9 rejettent la réponse.
• Conformité : Banques, gouvernements, santé et e-commerce exigent DNSSEC sur les domaines critiques.
• Détection proactive : Repérer DS orphelins, algorithmes faibles et signatures expirées avant la panne.

Comment utiliser le DNSSEC Checker en 3 étapes

Étape 1 : Entrez votre domaine

Saisissez le nom de domaine à vérifier (par exemple cloudflare.com ou nic.fr). L'outil accepte tout domaine, signé DNSSEC ou non. Si DNSSEC n'est pas activé, le résultat l'indique immédiatement.

Étape 2 : Choisissez le mode d'analyse

• Mode Simple (par défaut) : Vérifie la chaîne de confiance complète via un serveur autoritaire par zone. Résultat en 1 à 3 secondes.
• Mode Complet : Ajoute la cohérence DNSKEY entre tous les serveurs autoritaires. Valide aussi les signatures RRSIG sur SOA, NS, A et MX. Résultat en 5 à 10 secondes.

En cas de doute, commencez par le mode Simple. Utilisez le mode Complet après un rollover de clés, une migration DNS ou pour un audit de sécurité.

Étape 3 : Analysez le rapport et corrigez

Le rapport classe chaque anomalie par sévérité :

• Les erreurs bloquent la résolution. Chaîne cassée, signatures invalides, incohérence entre serveurs.
• Les avertissements nécessitent une action. DS orphelins, algorithmes faibles, RRSIG expirant bientôt.
• Les informations ne requièrent aucune action. CSK détectée, NS hors-bailiwick, nombre de DS au parent.

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

La chaîne de confiance DNSSEC (chain of trust) est un relais de vérifications cryptographiques en cascade. Chaque zone se porte garante de la suivante, de la racine DNS jusqu'à votre domaine :

Racine (.)
  |-- DS du TLD --> vérifie la DNSKEY du TLD (KSK)
  |-- La ZSK du TLD signe le DS de votre domaine
        |-- DS de votre domaine --> vérifie votre DNSKEY (KSK)
        |-- Votre KSK signe le DNSKEY RRSet
        |-- Votre ZSK signe les données (A, MX, SOA, NS)

Les enregistrements clés :

Chaque maillon dépend du précédent. Un seul maillon brisé et toute la chaîne s'effondre. Les résolveurs validants renvoient alors SERVFAIL.

NSEC et NSEC3 : la preuve authentifiée d'inexistence

DNSSEC ne signe pas seulement les enregistrements existants. Il prouve aussi, de façon authentifiée, qu'un nom ou un type d'enregistrement n'existe pas. Sans cette preuve, un attaquant pourrait nier l'existence d'un enregistrement pourtant signé. Deux mécanismes assurent cette preuve d'inexistence :

• NSEC (Next Secure) chaîne les noms de la zone par ordre alphabétique. Chaque enregistrement NSEC indique le nom existant suivant. L'inconvénient : en suivant cette chaîne de proche en proche, n'importe qui peut énumérer tous les noms de la zone. C'est le zone walking.
• NSEC3 (RFC 5155) corrige ce problème en publiant des hachages des noms plutôt que les noms en clair. Le zone walking devient beaucoup plus coûteux, car il faut casser les hachages. NSEC3 ajoute un sel (salt) et un nombre d'itérations.

L'opt-out NSEC3 est une option destinée aux très grandes zones (TLD, zones comptant de nombreuses délégations non signées). Il évite de générer une preuve NSEC3 pour les délégations non sécurisées, ce qui réduit la taille de la zone et le coût de signature. En contrepartie, l'opt-out n'authentifie pas l'absence de ces délégations.

Pour la plupart des domaines, NSEC ou NSEC3 conviennent. NSEC3 est préférable si vous voulez limiter l'énumération de votre zone.

Que vérifie exactement l'outil ?

Mode Simple

Mode Complet (en plus)

Diagnostics courants et solutions

DS orphelin (DNSSEC_DS_ORPHAN)

Symptôme : Un enregistrement DS est publié chez le parent mais aucune DNSKEY correspondante n'existe dans votre zone.

Cause probable : Rotation de clés incomplète. L'ancienne clé a été supprimée de la zone avant la mise à jour du DS chez le registrar.

Action : Supprimez le DS orphelin via votre registrar ou ajoutez la DNSKEY correspondante. Relancez le test pour confirmer.

Algorithme faible (DNSSEC_WEAK_ALGO)

Symptôme : Votre zone utilise un algorithme de signature considéré comme non sûr par la RFC 8624.

Algorithmes concernés : RSAMD5 (1), DSA (3) et DSA-NSEC3-SHA1 (6) sont interdits pour la signature. RSASHA1 (5) et RSASHA1-NSEC3-SHA1 (7) sont déconseillés.

Action : Migrez vers un algorithme recommandé : RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) ou Ed25519 (15). Relancez le test pour confirmer.

Digest SHA-1 (DNSSEC_WEAK_DIGEST)

Symptôme : Votre DS utilise SHA-1 (type 1) comme type de digest.

Action : Ajoutez un DS SHA-256 (type 2), ou SHA-384 (type 4) si votre registrar le supporte, en parallèle. Attendez 48h de propagation, puis supprimez le DS SHA-1. Relancez le test pour confirmer.

SERVFAIL après activation DNSSEC

Symptôme : Votre domaine renvoie SERVFAIL pour les résolveurs validants après activation de DNSSEC.

Causes fréquentes :

• DS au registrar ne correspond pas à la DNSKEY de votre zone
• Signatures RRSIG non générées ou expirées
• Serveurs autoritaires ne servant pas les enregistrements DNSKEY

Action : Lancez le test en mode Complet pour identifier le maillon cassé. Vérifiez que le DS correspond à la DNSKEY KSK. Relancez le test pour confirmer.

Incohérence DNSKEY entre serveurs (DNSSEC_SERVER_INCONSISTENT)

Symptôme : Les serveurs autoritaires de votre zone ne servent pas les mêmes clés DNSKEY. Détecté uniquement en mode Complet.

Cause probable : Propagation incomplète entre serveurs primaire et secondaires, ou configuration différente sur un serveur.

Action : Vérifiez la réplication entre serveurs. Forcez un transfert de zone (AXFR/IXFR) si nécessaire. Relancez le test pour confirmer.

Vérifier DNSSEC en ligne de commande (delv et dig)

Pour les administrateurs système, deux outils permettent de vérifier DNSSEC manuellement. delv (livré avec BIND 9.10 et plus récent) effectue une validation complète de la chaîne de confiance et affiche un verdict final. dig interroge les enregistrements bruts (DS, DNSKEY, RRSIG) mais ne valide pas la chaîne lui-même.

Note : les anciennes options dig +sigchase et +trusted-key ont été retirées des versions modernes de BIND. Utilisez delv à leur place pour la validation.

# Valider la chaîne de confiance complète (verdict final)
delv captaindns.com A

# Tracer chaque étape de la validation
delv @1.1.1.1 captaindns.com A +rtrace

# Valider et afficher les DNSKEY de la zone
delv captaindns.com DNSKEY

# Voir les enregistrements DS publiés chez le parent
dig DS captaindns.com +short

# Voir les DNSKEY et leurs signatures RRSIG (sans validation)
dig DNSKEY captaindns.com +dnssec

# Voir les RRSIG sur un enregistrement A
dig A captaindns.com +dnssec

Une réponse delv validée affiche ; fully validated ; un échec de validation affiche ; resolution failed. Ces commandes nécessitent un accès terminal et une expertise DNS. Le DNSSEC Checker ci-dessus automatise tout le processus et présente les résultats visuellement, sans ligne de commande.

DNSSEC par hébergeur DNS

L'activation de DNSSEC dépend de votre hébergeur DNS et de votre registrar. Voici les principaux providers et leur niveau de support :

Après activation, vérifiez toujours la chaîne de confiance avec le DNSSEC Checker. L'erreur n°1 : un DS au registrar qui ne correspond pas à la DNSKEY générée par l'hébergeur.

Bonnes pratiques DNSSEC

Algorithme de signature : Privilégiez un algorithme à courbe elliptique, ECDSAP256SHA256 (13) ou Ed25519 (15). RSASHA256 (8) et ECDSAP384SHA384 (14) restent largement déployés et acceptés. ECDSA produit des signatures environ 3,5 à 4 fois plus compactes que RSA-2048, ce qui réduit la taille des réponses.

Digest DS : Publiez un DS avec SHA-256 (type 2) ; SHA-384 (type 4) est également accepté. SHA-1 (type 1) est déprécié : ne publiez plus de DS SHA-1 seul.

Rotation de clés : Suivez les pratiques des RFC 6781 et 7583 (voir la section dédiée plus bas). Ne supprimez jamais l'ancien DS avant propagation du nouveau.

Monitoring : Vérifiez la chaîne après chaque modification DNS. Une zone non re-signée à temps provoque des SERVFAIL.

Migration de provider : Confirmez que le nouveau provider supporte le même algorithme. Les deux jeux de clés doivent coexister pendant la propagation.

Rotation des clés de signature (rollover)

Une clé DNSSEC n'est pas éternelle. Il faut la remplacer périodiquement (rollover) sans casser la chaîne de confiance. Les RFC 6781 (pratiques opérationnelles) et 7583 (calendrier de rotation) décrivent ces procédures. Le mode opératoire diffère selon le type de clé.

Rollover de KSK (Key Signing Key). La KSK est référencée par le DS chez le parent. La méthode courante est le double-DS : publiez le DS de la nouvelle KSK chez le parent, attendez que tous les caches aient pris en compte les deux DS, basculez la signature du DNSKEY RRSet sur la nouvelle KSK, puis retirez l'ancien DS. Le délai dépend du TTL du DS chez le parent.

Rollover de ZSK (Zone Signing Key). La ZSK signe les données et n'est pas liée au parent. Deux méthodes :

• Pre-publish : publiez la nouvelle ZSK dans le DNSKEY RRSet avant de l'utiliser, attendez la propagation, signez les données avec la nouvelle clé, puis retirez l'ancienne. C'est la méthode recommandée pour la ZSK.
• Double-signature : signez les données avec l'ancienne et la nouvelle ZSK simultanément. Plus simple à appréhender, mais double le nombre de signatures et alourdit les réponses.

Risques d'un rollover raté. Retirer une clé ou un DS avant l'expiration des caches qui s'y réfèrent casse la chaîne : les résolveurs validants renvoient SERVFAIL. Ne supprimez jamais l'ancienne clé ou l'ancien DS avant que tous les TTL concernés aient expiré. Vérifiez l'absence de DS orphelin après chaque rollover de KSK.

CDS et CDNSKEY : automatiser le DS chez le parent

Le point faible d'un rollover de KSK est la mise à jour manuelle du DS chez le registrar. Un copier-coller erroné casse la chaîne. Les enregistrements CDS et CDNSKEY (RFC 7344 et 8078) automatisent cette étape.

La zone enfant publie un CDS (Child DS) ou un CDNSKEY (Child DNSKEY) qui indique au parent le DS à publier. Le registrar ou le registre scanne périodiquement ces enregistrements et met à jour le DS automatiquement, sans intervention manuelle. Deux usages :

• Amorçage (bootstrapping, RFC 8078) : la première activation de DNSSEC, lorsqu'aucun DS n'existe encore chez le parent.
• Maintenance : la mise à jour du DS lors des rollovers de KSK suivants.

Tous les registres ne prennent pas encore en charge CDS/CDNSKEY, mais l'adoption progresse. Quand ils sont supportés, ils éliminent la principale source d'erreur des rollovers de KSK. Vérifiez ensuite la chaîne avec le DNSSEC Checker pour confirmer que le DS publié correspond bien à votre KSK.

Cas d'usage concrets

Activation DNSSEC chez un nouveau registrar

Vous venez d'activer DNSSEC ? Lancez une vérification en mode Simple. Confirmez que le DS au parent correspond à la DNSKEY de votre zone. La chaîne doit être complète de bout en bout.

Rotation de clés (key rollover)

Vous effectuez un key rollover ? Vérifiez l'absence de DS orphelins avec le mode Simple. Un ancien DS non supprimé ne casse pas la résolution. Il complique cependant les futurs rollovers.

Migration de provider DNS

Vous migrez vers Cloudflare ? Route 53 ? Lancez le test en mode Complet. Vérifiez que les DS pointent vers les nouvelles DNSKEY. Confirmez la validité des signatures sur tous les serveurs autoritaires.

Audit de sécurité

Le mode Complet couvre les trois piliers d'un audit DNSSEC. Cohérence DNSKEY entre serveurs. Signatures valides sur SOA, NS, A et MX. Alerte sur les RRSIG proches de l'expiration.

Domaine renvoyant SERVFAIL

Votre site est inaccessible depuis certains réseaux ? Ces réseaux utilisent probablement des résolveurs validants. Lancez le test immédiatement pour identifier si DNSSEC est en cause.

❓ FAQ - Questions fréquentes

Q : DNSSEC, c'est quoi et pourquoi l'activer ?

R : DNSSEC ajoute des signatures cryptographiques aux réponses DNS. Sans DNSSEC, un attaquant peut falsifier les réponses et rediriger le trafic. Activer DNSSEC garantit que les visiteurs atteignent vos serveurs, pas ceux d'un attaquant.

Q : Comment vérifier si DNSSEC est activé sur mon domaine ?

R : Entrez votre domaine dans l'outil ci-dessus. S'il affiche "DNSSEC n'est pas activé", aucun DS n'est publié chez le parent. Contactez votre registrar pour activer DNSSEC.

Q : Qu'est-ce qu'un DS orphelin ?

R : Un DS au parent sans DNSKEY correspondante dans la zone enfant. Cela arrive lors d'une rotation de clés incomplète. Pas bloquant tant qu'un autre DS valide existe, mais signe de configuration incomplète.

Q : Pourquoi mon domaine renvoie SERVFAIL après activation de DNSSEC ?

R : La chaîne de confiance est cassée. Causes fréquentes : DS ne correspondant pas à la DNSKEY, RRSIG absentes ou expirées, DNSKEY non servies. Lancez le mode Complet pour identifier le maillon défaillant.

Q : Quelle est la différence entre les modes Simple et Complet ?

R : Simple vérifie la chaîne DS/DNSKEY/RRSIG sur un serveur par zone. Complet ajoute la cohérence DNSKEY multi-serveurs et valide les RRSIG sur SOA, NS, A et MX.

Q : Quels algorithmes DNSSEC sont recommandés ?

R : Les algorithmes courants et recommandés sont RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) et Ed25519 (15). Selon la RFC 8624, RSAMD5 (1), DSA (3) et DSA-NSEC3-SHA1 (6) sont interdits ; RSASHA1 (5) et RSASHA1-NSEC3-SHA1 (7) sont déconseillés.

Q : NSEC ou NSEC3 : qu'est-ce que le zone walking ?

R : NSEC et NSEC3 prouvent de façon authentifiée qu'un nom n'existe pas. NSEC liste les noms en clair, ce qui permet d'énumérer toute la zone (zone walking). NSEC3 (RFC 5155) publie des hachages à la place des noms pour empêcher cette énumération.

Q : À quoi servent les enregistrements CDS et CDNSKEY ?

R : CDS et CDNSKEY (RFC 7344 et 8078) permettent à la zone enfant de signaler au parent le DS à publier. Le registrar ou le registre scanne ces enregistrements pour créer puis maintenir automatiquement le DS, sans copier-coller manuel à chaque rotation de KSK.

Q : DNSSEC ralentit-il la résolution DNS ?

R : L'impact reste limité, mais les réponses signées sont plus volumineuses. Elles peuvent dépasser la taille d'un paquet UDP et provoquer une fragmentation ou un repli sur TCP. Les résolveurs mettent en cache les résultats validés, ce qui amortit le coût après la première requête.

Outils complémentaires

Ressources utiles

• RFC 4033 - DNS Security Introduction : Introduction et exigences des extensions DNSSEC
• RFC 4034 - Resource Records for DNSSEC : Spécification des enregistrements DS, DNSKEY, RRSIG, NSEC
• RFC 4035 - Protocol Modifications for DNSSEC : Comportement des résolveurs et serveurs validants
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence : Spécification de NSEC3
• RFC 6781 - DNSSEC Operational Practices : Bonnes pratiques opérationnelles et rollovers
• RFC 7583 - DNSSEC Key Rollover Timing : Calendrier de rotation des clés
• RFC 8624 - Algorithm Implementation Requirements : Exigences sur les algorithmes DNSSEC
• Verisign DNSSEC Debugger : Outil de référence pour le debug DNSSEC
• DNSViz : Visualisation avancée de la chaîne DNSSEC