Test DNSSEC
Saisissez un domaine et nous suivons sa chaîne de signatures depuis la zone racine. Vous saurez si le domaine est non signé, signé et valide, à moitié configuré ou cassé et quel enregistrement corriger.
La faille que DNSSEC referme
Quand votre ordinateur demande « quelle est l’adresse de example.com ? », la réponse revient dans un petit paquet non protégé. Le DNS d’origine ne donne au destinataire aucun moyen de vérifier qui l’a écrite. Quelqu’un placé entre vous et le serveur de noms, ou quelqu’un qui glisse une fausse réponse dans la mémoire d’un résolveur, peut envoyer les visiteurs et le courrier vers une machine de son choix.
DNSSEC ajoute des signatures. Le propriétaire d’une zone signe chaque jeu d’enregistrements avec une clé privée et publie la clé publique correspondante dans la zone sous forme d’enregistrement DNSKEY. Un résolveur qui reçoit une réponse reçoit aussi sa signature (RRSIG) et peut vérifier que les enregistrements sont exactement ceux que le propriétaire a publiés. DNSSEC ne chiffre rien et ne cache pas les noms que vous recherchez. Il se contente de prouver qu’une réponse est authentique.
Une chaîne d’empreintes
Une clé publique placée au même endroit que les données ne prouve pas grand-chose, puisqu’un faussaire pourrait remplacer les deux. Chaque zone demande donc à la zone au-dessus de se porter garante. Le parent publie un enregistrement DS, une courte empreinte (condensat) de la clé de l’enfant et signe cet enregistrement avec sa propre clé. La clé du parent est garantie de la même façon par son propre parent, jusqu’à la zone racine. La clé de la racine est la seule chose qu’un résolveur doit connaître d’avance et elle est livrée avec le logiciel du résolveur.
Pour example.com, le chemin est le suivant : clé de la racine, DS de com dans la racine, clés de com, DS de example.com dans com, clés de example.com, enregistrements signés. Un seul maillon manquant ou faux et la preuve échoue.
L’enregistrement DS est la partie qui vit hors de votre hébergeur DNS. Il est transmis au registre par votre registraire et la plupart des pannes viennent de cette séparation.
Ce que fait ce test
Pour la racine, la zone de premier niveau et chaque zone jusqu’à votre domaine, notre serveur lit les enregistrements DS chez le parent et les enregistrements DNSKEY de la zone. Il les lit par des résolveurs publics dont la validation est désactivée (le drapeau « checking disabled »), ce qui lui permet d’inspecter une zone cassée. Pour chaque clé, il calcule l’identifiant de clé (key tag). Pour chaque DS, il recalcule le condensat à partir de la clé avec la même fonction de hachage (RFC 4034) et compare les deux octet par octet.
Il interroge ensuite trois résolveurs publics validants (Cloudflare, Google et Quad9) sur l’enregistrement SOA du domaine, cette fois avec la validation activée. Un résolveur qui a validé la réponse active le drapeau AD (« authenticated data »). Celui qui a trouvé une faute répond SERVFAIL. Notre serveur compare lui-même les empreintes, mais il ne vérifie pas les signatures. Ce verdict revient aux résolveurs.
| Verdict | Ce qui a été trouvé | Effet |
|---|---|---|
| Non signé | Ni DS, ni DNSKEY | Fonctionne partout, les réponses ne peuvent pas être vérifiées. La plupart des domaines. |
| Signé et valide | Le DS correspond à une clé, les résolveurs activent AD | Les résolveurs validants rejettent les fausses réponses. |
| À moitié configuré | DNSKEY présent, pas de DS | Fonctionne, mais personne ne vérifie les signatures. |
| Cassé | DS sans clé correspondante, ou SERVFAIL seulement quand la validation est active | Inaccessible pour tous ceux qui passent par un résolveur validant. |
Le test signale aussi les algorithmes retirés ou faibles (RSA/MD5, DSA, RSA/SHA-1, condensats SHA-1 dans un DS), un DS resté d’une ancienne clé, des signatures à moins de trois jours de leur date de fin et si la zone utilise NSEC ou NSEC3 pour prouver qu’un nom n’existe pas.
Réparer une chaîne cassée
Une chaîne cassée est pire que pas de DNSSEC du tout, parce que les résolveurs validants refusent de répondre. Cela se passe d’ordinaire ainsi : le domaine a changé d’hébergeur DNS, l’ancien enregistrement DS est resté chez le registraire et il pointe maintenant vers une clé qui n’existe plus.
- Pour revenir en ligne vite, supprimez l’enregistrement
DSchez le registraire. Le domaine devient non signé et fonctionne pour tout le monde une fois les caches expirés, en général en moins d’un jour. - Pour garder DNSSEC, ouvrez la page DNSSEC de votre hébergeur DNS actuel, copiez l’enregistrement
DSqu’elle affiche (key tag, algorithme, type de condensat, condensat) et saisissez-le chez le registraire à la place de l’ancien. - Avant le prochain changement, retirez d’abord l’enregistrement
DS, attendez un jour, changez les serveurs de noms, puis signez et publiez le nouveauDS.
Pour « à moitié configuré », terminez le travail en publiant l’enregistrement DS ou désactivez la signature chez l’hébergeur DNS.
Les résolveurs conservent les réponses, échecs compris, aussi longtemps que le TTL de l’enregistrement le permet. Juste après une correction, cette page peut montrer l’ancien état un moment et des résolveurs différents peuvent ne pas être d’accord.
Questions fréquentes
Ai-je besoin de DNSSEC sur mon domaine ?
C’est facultatif et la plupart des domaines s’en passent. Il protège les visiteurs et le courrier contre les fausses réponses DNS et quelques usages l’exigent, comme DANE pour les serveurs de messagerie. Si votre hébergeur DNS et votre registraire le gèrent d’un seul interrupteur, l’activer coûte peu. Si vous changez souvent d’hébergeur DNS, préparez chaque changement avec soin.
Quelle est la différence entre un enregistrement DS et un enregistrement DNSKEY ?
Un DNSKEY est une clé publique, publiée dans votre propre zone par votre hébergeur DNS. Un DS est une empreinte de cette clé, publiée dans la zone parente (.com, .org) par l’intermédiaire de votre registraire. Le DS est ce qui rattache votre zone à la chaîne.
Pourquoi mon site fonctionne-t-il pour moi mais pas pour les autres ?
Si DNSSEC est cassé, ce qui se passe dépend du résolveur de chaque visiteur. Les résolveurs qui valident (Google, Cloudflare, Quad9, beaucoup de grands fournisseurs) renvoient une erreur. Ceux qui ne valident pas répondent quand même. Lancez le test. Un verdict « cassé » avec « validation désactivée : répond » correspond exactement à cette situation.
Que sont KSK et ZSK ?
Deux rôles de clés dans une zone. La clé de signature de clés (KSK, drapeau 257) signe seulement le jeu de clés et c’est elle que l’enregistrement DS désigne. La clé de signature de zone (ZSK, drapeau 256) signe tous les autres enregistrements et peut être remplacée sans toucher au registraire. Certains hébergeurs utilisent une seule clé pour les deux.
Quel algorithme DNSSEC une zone doit-elle utiliser ?
L’algorithme 13 (ECDSA P-256 avec SHA-256) est le choix courant aujourd’hui, avec de petites signatures et une large prise en charge. L’algorithme 8 (RSA avec SHA-256) convient aussi. Les algorithmes 5 et 7 reposent sur SHA-1 et doivent être remplacés. Les algorithmes 1, 3, 6 et 12 sont retirés.
Combien de temps faut-il pour qu’un changement DNSSEC apparaisse ?
Un changement de DS parvient au registre en quelques minutes au plus chez la plupart des registraires, mais les résolveurs gardent l’ancien DS pendant son TTL, souvent 24 heures pour .com. Laissez passer une journée entière avant de juger le résultat.