DNSSEC : DS, DNSKEY et RRSIG

Ce que DNSSEC promet, et ce qu’il ne promet pas

Sans DNSSEC, un résolveur fait confiance au serveur qu’il vient d’interroger. Si quelqu’un se place sur le chemin et renvoie une autre adresse, le résolveur peut l’accepter et la mettre en cache. DNSSEC ajoute une vérification : la zone signe ses enregistrements, et le résolveur contrôle la signature avec une clé dont l’empreinte est publiée par le parent. Si le contrôle échoue, un résolveur qui valide ne donne pas la réponse douteuse. Il échoue, souvent avec SERVFAIL.

DNSSEC ne chiffre pas les questions ni les réponses. Un observateur du réseau voit encore le nom demandé, sauf si un autre mécanisme protège le transport entre le client et le résolveur. DNSSEC ne décide pas non plus qui est le titulaire du domaine : c’est le registre et le registraire. Il ne remplace pas TLS. Un site peut avoir une chaîne DNSSEC valide et un certificat expiré, ou l’inverse. Le drapeau ad (authenticated data) dans une réponse de résolveur dit seulement : « j’ai vérifié les signatures DNS de cette réponse ».

Le 23 octobre 2026, la réponse A d’example.com chez 1.1.1.1 portait les drapeaux qr rd ra ad. Le bit ad était présent. Le même jour, la réponse A de dnssec-failed.org ne l’avait pas : le statut était SERVFAIL, et le serveur ajoutait une information étendue EDE 9, « DNSKEY Missing », avec le texte « no SEP matching the DS found for dnssec-failed.org ». Ce domaine sert justement à illustrer une chaîne cassée. Ce n’est pas un incident du moment, c’est un échec reproductible.

Trois enregistrements, trois étages

La clé publique de la zone est un enregistrement DNSKEY. Certaines clés signent les données ordinaires (on les appelle parfois ZSK). Une clé plus durable signe ces clés et sert de point d’appui (KSK). On les distingue dans les drapeaux du DNSKEY, pas dans un type différent. Le 23 octobre 2026, example.com publiait plusieurs DNSKEY d’algorithme 13. L’une d’elles, avec le drapeau 257, était :

example.com. 258 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==

Le parent ne republie pas cette clé en entier. Il publie un DS : un numéro de clé, l’algorithme, le type d’empreinte, et l’empreinte. Le même jour, 1.1.1.1 renvoyait :

example.com. 86400 IN DS 2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1C83D245A

Le numéro 2371 et l’algorithme 13 doivent correspondre à une DNSKEY réellement présente dans la zone. Le DS vit chez le parent, donc pour un domaine il se dépose via le registraire ou le registre, pas seulement dans le fichier de zone enfant. Oublier cette marche est l’erreur la plus fréquente au moment d’activer ou de renouveler une clé.

Le RRSIG est la signature d’un ensemble d’enregistrements. Il porte les dates de validité, l’algorithme et le numéro de la clé qui a signé. Le RRSIG du DS d’example.com, vu le 23 octobre 2026, couvrait une fenêtre allant jusqu’au 28 octobre 2026 01:32:16 UTC (20261028013216). Une signature expirée ne se « propage » pas : dès qu’un résolveur validant la voit, il refuse. Les horloges des serveurs comptent. Une machine à l’heure fausse signe pour une fenêtre que personne n’accepte.

Pourquoi on parle de chaîne

Le résolveur connaît d’avance des clés de la racine, installées avec le logiciel. La racine signe la délégation de com et publie un DS. La zone com signe son DS d’example.com. La zone example.com signe ses A, ses NS, son SOA. Chaque maillon est vérifiable à partir du précédent. Si un seul maillon manque, la chaîne s’arrête. Le résolveur validant n’a pas de demi-confiance : il ne sert pas les données non authentifiées quand la zone est censée être signée.

Une zone non signée, sans DS chez le parent, est simplement non signée. Le résolveur répond quand même, sans poser le drapeau ad. Le passage de « pas de DS » à « DS publié » est donc un engagement : à partir de ce moment, une signature absente ou fausse devient une panne pour les utilisateurs des résolveurs qui valident. On n’active le DS qu’après avoir vu des RRSIG frais en interrogeant les autoritatifs.

Le retrait suit l’ordre inverse. On retire d’abord le DS chez le parent, on attend que les caches de ce DS expirent, et seulement ensuite on arrête de signer. Retirer les signatures avant le DS laisse les résolveurs avec un DS qui ne correspond plus à rien : c’est le scénario « DNSKEY Missing » observé sur dnssec-failed.org.

Ce qu’il suffit de vérifier

Vous n’avez pas à recalculer une empreinte à la main pour un contrôle de routine. Trois questions suffisent. Un résolveur validant (1.1.1.1, 8.8.8.8 ou 9.9.9.9) répond-il NOERROR avec ad pour le A du nom ? Le DS vu chez ce résolveur a-t-il le même numéro de clé qu’une DNSKEY de la zone ? Les dates du RRSIG entourent-elles le moment du test ? Si le résolveur renvoie SERVFAIL alors que l’autoritatif, interrogé directement, montre encore des A, la piste DNSSEC passe devant la piste « le site est tombé ».

Les interfaces hébergées cachent souvent les RRSIG et ne montrent qu’un interrupteur. L’interrupteur doit rester cohérent avec le DS déposé au registraire. Deux prestataires qui proposent chacun « activer DNSSEC » sans que vous sachiez qui publie le DS produisent exactement une chaîne cassée. Le guide délégation et registraire rappelle où se règle le DS : au même endroit que la délégation, pas dans le seul éditeur de zone.

L’outil de ce site ne valide pas les signatures à votre place et ne demande pas le type DNSKEY : il compare les types du quotidien. Pour un SERVFAIL inexpliqué, enchaînez avec le diagnostic et, si besoin, un dig manuel +dnssec vers un résolveur et vers l’autoritatif. Le lexique fixe les définitions de DNSSEC, du DS et du SERVFAIL utilisées ici.