Vérificateur DNSSEC

Interroge l'enregistrement DNSKEY d'un domaine auprès de plusieurs résolveurs DNS publics (Google, Cloudflare, etc.) pour vérifier si sa chaîne de signatures DNSSEC est validée correctement.

Astuces

  • L'indicateur AD (Authenticated Data) n'est activé que lorsque le résolveur DNS interrogé a lui-même effectué la validation DNSSEC. Les résolveurs qui ne prennent pas en charge DNSSEC ne peuvent pas fournir de résultat significatif.
  • « DNSSEC non activé » n'est pas une erreur : la majorité des domaines n'utilisent toujours pas DNSSEC, ce qui n'a aucun effet direct sur le classement dans les moteurs de recherche ni sur la délivrabilité des e-mails.
  • Si la validation échoue, vérifiez d'abord que le key tag et le condensé de l'enregistrement DS déclaré chez votre registrar correspondent à votre DNSKEY actuel.
  • Les signatures DNSSEC (RRSIG) ont une date d'expiration. Vérifiez aussi que la re-signature automatique de votre logiciel DNS n'a pas été interrompue.
  • Juste après l'activation de DNSSEC, la validation peut brièvement s'afficher comme « échouée » le temps que l'enregistrement DS se propage jusqu'à la zone parente.

Foire aux questions

« DNSSEC non activé » n'est pas dangereux en soi : la grande majorité des domaines fonctionnent encore sans lui. Cela dit, l'activer mérite d'être envisagé comme protection contre l'empoisonnement de cache DNS si l'option est disponible.

Les utilisateurs de résolveurs qui imposent DNSSEC (de nombreux réseaux d'entreprise et certains fournisseurs d'accès) peuvent ne plus du tout pouvoir résoudre le domaine, celui-ci étant traité comme SERVFAIL. Sauf s'il s'agit d'un état temporaire juste après l'activation de DNSSEC, le temps que l'enregistrement DS se propage, une correction rapide est nécessaire.

Juste après une rotation de DNSKEY, les anciennes et nouvelles clés peuvent coexister brièvement dans les caches des résolveurs, entraînant des résultats de validation temporairement différents. Patientez un peu puis vérifiez à nouveau.

Non. DNSSEC garantit qu'une réponse de résolution de nom n'a pas été falsifiée, tandis que SSL/TLS garantit que la connexion elle-même est chiffrée et que le serveur détient bien le certificat présenté. Les deux sont indépendants — un domaine peut avoir l'un sans l'autre.

Cet outil ne vérifie qu'un état de surface : si une DNSKEY est publiée et si les résolveurs signalent l'indicateur AD. Pour une analyse rigoureuse de l'ensemble de la chaîne de signatures (cohérence RRSIG/NSEC/NSEC3, etc.), associez-le à un outil spécialisé comme dnsviz.net.
ツールくん

Anecdote — pourquoi le DNS a eu besoin d'un moyen d'empêcher l'usurpation

Lorsque le DNS a été conçu en 1983, il n'existait aucun moyen cryptographique de confirmer qui envoyait réellement une réponse. Un résolveur faisait confiance à tout paquet UDP arrivant avec un identifiant de transaction d'apparence plausible — un protocole bâti sur la bonne foi, vulnérable à l'usurpation d'adresse IP source et à la devinette d'identifiants. En 2008, le chercheur en sécurité Dan Kaminsky a montré à l'industrie que cette faiblesse pouvait être exploitée pour mener des attaques d'empoisonnement de cache rapides et pratiques (injecter de faux enregistrements dans le cache d'un résolveur), une découverte qui a secoué toute la communauté DNS.

DNSSEC (DNS Security Extensions) est la réponse normalisée à ce problème. Il utilise la cryptographie à clé publique pour prouver qu'une réponse a été signée par l'opérateur légitime de la zone. Un domaine signe ses enregistrements avec sa DNSKEY, et un enregistrement DS déclaré dans la zone parente atteste du condensé de cette clé, construisant ainsi une chaîne de confiance ininterrompue depuis la racine du DNS jusqu'au domaine individuel.

L'indicateur AD (Authenticated Data) d'une réponse DoH (DNS over HTTPS) résulte de cette validation DNSSEC effectuée par le résolveur en votre nom. Les applications n'ont pas besoin d'implémenter elles-mêmes la vérification des signatures : interroger un résolveur de confiance et obtenir AD=true constitue une garantie indirecte que la réponse n'a pas été falsifiée, à condition que le transport entre le résolveur et l'application (HTTPS) soit lui-même sécurisé.