Test DNS › Guides DNS

DNSSEC : principes de signature et de validation

Le DNS d'origine ne vérifie rien : une réponse arrive, elle est crue. DNSSEC ajoute des signatures pour que le résolveur puisse distinguer une réponse authentique d'une réponse forgée, au prix d'une chaîne de confiance à construire depuis la racine jusqu'à la zone.

Trousseau de clés métalliques posé sur un clavier d'ordinateur — DNSSEC repose sur des clés publiées et des signatures : la sécurité vient de la vérification, pas du secret des noms.

Le problème que DNSSEC résout

Une réponse DNS classique n'est accompagnée d'aucune preuve d'origine. Un intermédiaire capable d'injecter un paquet peut fournir une adresse fausse, et le résolveur la mettra en cache comme une réponse légitime. DNSSEC apporte l'authentification de l'origine et l'intégrité des données : la réponse vient bien de la zone annoncée et n'a pas été modifiée en chemin.

DNSSEC ne chiffre rien. Les noms interrogés et les réponses restent lisibles par un observateur du réseau, ce qui explique la coexistence avec les transports chiffrés comme DNS sur TLS ou DNS sur HTTPS, qui traitent la confidentialité du trajet. Confondre les deux objectifs conduit à des attentes fausses, notamment sur la protection des noms consultés.

Le mécanisme couvre aussi l'absence : lorsqu'un nom n'existe pas, la zone signe une preuve de non-existence. Sans cela, un attaquant pourrait simplement répondre que le nom n'existe pas, et le résolveur n'aurait aucun moyen de le contredire.

Clés, signatures et chaîne de confiance

Une zone signée publie ses clés publiques dans des enregistrements DNSKEY, et une signature RRSIG pour chaque ensemble d'enregistrements. Le résolveur qui connaît la clé publique peut vérifier que l'ensemble n'a pas été altéré. Les formats et les règles de traitement sont décrits dans les RFC 4034 et 4035, la RFC 4033 posant l'architecture d'ensemble.

Reste à savoir si la clé publique elle-même est authentique. La réponse tient dans l'enregistrement DS, publié par la zone parente : il contient l'empreinte d'une clé de la zone enfant, signée par le parent. Le résolveur valide ainsi de proche en proche, depuis la clé racine qu'il connaît par configuration, jusqu'à la zone interrogée. Cette succession de délégations signées est la chaîne de confiance, et elle s'interrompt dès qu'un maillon manque.

Prouver l'absence avec NSEC et NSEC3

Signer une réponse affirmative est simple ; prouver qu'un nom n'existe pas demande de signer autre chose. La première approche, NSEC, chaîne les noms existants dans l'ordre canonique : la réponse indique entre quels noms existants le nom cherché tomberait, et cette affirmation est signée. Elle a l'inconvénient de révéler l'inventaire de la zone à qui sait l'explorer.

NSEC3, défini dans la RFC 5155, remplace les noms par leur empreinte cryptographique, ce qui limite cette énumération. Les deux mécanismes coexistent, et le choix a des conséquences opérationnelles : coût de calcul à la signature, taille des réponses, et comportement des résolveurs anciens. Un changement de mécanisme sur une zone en production se prépare, il ne s'improvise pas.

La validation se fait chez le résolveur

Un client ne valide généralement pas : il fait confiance à son résolveur. C'est le résolveur récursif qui remonte la chaîne, vérifie les signatures et décide. Quand tout est valide, il peut marquer la réponse comme authentifiée ; quand la validation échoue, il doit renvoyer une erreur de résolution plutôt qu'une réponse douteuse.

Cette règle explique le symptôme le plus déroutant de DNSSEC : un domaine qui fonctionne pour certains utilisateurs et pas pour d'autres. Les résolveurs qui valident échouent, ceux qui ne valident pas répondent normalement. Avant d'accuser le réseau, il faut donc savoir si le résolveur en face pratique la validation, et lire le code d'erreur renvoyé plutôt que le nom du site.

Exploiter une zone signée

Une zone signée a une durée de vie : les signatures expirent, et le résolveur refuse alors les réponses. Le renouvellement doit être automatique, avec une alerte sur l'âge de la signature la plus ancienne. Un serveur de noms moderne sait gérer une politique de signature qui reprend ce travail, à condition que l'horloge de la machine soit juste : une dérive d'horloge suffit à invalider toutes les signatures.

Les clés se renouvellent aussi, et la procédure de transition doit être écrite avant d'être nécessaire. La clé de signature de zone, renouvelée souvent, ne demande qu'une republication ; la clé de la délégation, dont l'empreinte figure chez le parent, exige une coordination avec le registraire ou avec l'opérateur de la zone parente. Une rotation manquée à ce niveau rend le domaine invalide pour tous les résolveurs validants.

Les erreurs qui cassent la résolution

Trois erreurs reviennent. Signer une zone sans publier l'enregistrement DS chez le parent : les signatures existent mais aucune chaîne ne les relie à la racine, la zone reste non validée, ce qui est sans danger mais sans effet. Publier un DS pour une zone non signée : le domaine devient invalide pour tous les résolveurs validants. Changer de clé sans mettre à jour le DS : même résultat, souvent après quelques jours de fonctionnement normal.

La quatrième erreur est plus discrète : conserver des algorithmes ou des tailles de clés que les recommandations considèrent comme obsolètes. Le domaine continue de fonctionner, puis cesse brusquement lorsque les résolveurs retirent la prise en charge. La RFC 8624 tient à jour ces recommandations, et mérite une relecture à chaque revue d'architecture plutôt qu'en situation d'urgence.

Sources

Pour vérifier un nom de domaine en direct — racine, TLD, serveurs de noms — utilisez l'outil de test DNS. Demarcq.net assure l'exploitation de serveurs DNS : les prestations d'exploitation.

← Mettre en place un DNS secondaire : intérêt, limites et bonnes pratiques TTL et propagation des changements de zone →