DNSSEC : chaîne de confiance, validation et exploitation des clés

DNSSEC : chaîne de confiance, validation et exploitation des clés

DNSSEC (Domain Name System Security Extensions) signe les enregistrements DNS (Domain Name System) pour qu’un résolveur puisse vérifier qu’une réponse vient bien de la zone qui fait autorité et n’a pas été modifiée en route. Il ne chiffre rien : la question et la réponse circulent toujours en clair. Cette page décrit les enregistrements, la chaîne de confiance depuis la racine, la validation et ce qu’il faut tenir en exploitation pour que la signature ne devienne pas la première cause d’indisponibilité de la zone.

Explication de la marmotte

Quand on demande son chemin à un inconnu dans la rue, rien ne prouve qu’il ne ment pas. Ce mécanisme ajoute un tampon officiel sur chaque réponse donnée par l’annuaire d’Internet, pour qu’on puisse vérifier qu’elle vient bien du bon endroit. Le tampon ne cache rien : tout le monde peut lire la réponse, mais personne ne peut la falsifier.

→ Lire l’explication complète de la marmotte

Empoisonnement de cache DNS et attaque de Kaminsky : le problème que DNSSEC résout

Un résolveur récursif interroge des serveurs faisant autorité en UDP (User Datagram Protocol), sans session ni authentification. Pour accepter une réponse, il vérifie le nom demandé, le port source et un identifiant de transaction de 16 bits. Un attaquant hors chemin qui devine ces valeurs et répond avant le vrai serveur fait entrer une réponse forgée dans le cache, servie ensuite à tous les clients jusqu’à expiration du TTL (Time To Live).

En 2008, Dan Kaminsky a rendu cette attaque industrielle. Au lieu de viser www.example.com (déjà en cache, donc une seule tentative par TTL), l’attaquant fait demander a1.example.com, a2.example.com, et ainsi de suite. Chaque nom inexistant ouvre une nouvelle course, et la réponse forgée ne se contente pas de l’adresse : elle injecte une délégation qui désigne les serveurs de l’attaquant comme autoritaires pour tout example.com. La parade d’urgence, la randomisation du port source (formalisée dans la RFC 5452, Request for Comments), porte l’entropie d’environ 16 à environ 32 bits. Elle augmente le coût de l’attaque sans en changer la nature : c’est toujours un pari sur des valeurs devinables, et un NAT (Network Address Translation) qui réécrit les ports séquentiellement l’annule.

DNSSEC remplace le pari par une preuve. Une réponse forgée ne porte pas de signature valide, le résolveur validant la rejette, quelle que soit la qualité de la course gagnée.

Ce que DNSSEC ne résout pas, et qu’il faut aller chercher ailleurs :

• La confidentialité. Les requêtes restent lisibles par tout observateur du chemin. C’est le rôle de DoT (DNS over TLS) ou DoH (DNS over HTTPS), décrits dans DNS over TLS.
• Le dernier kilomètre. La validation se fait sur le résolveur récursif. Entre ce résolveur et le poste client, la réponse circule en clair et sans signature exploitable par le client ; un attaquant sur le réseau local réécrit la réponse et le drapeau qui affirme « validé ».
• La disponibilité. DNSSEC ajoute des modes de panne ; il n’en retire aucun.
• La justesse des données. Une zone signée avec une adresse erronée publie une erreur authentique. La signature atteste l’origine, pas le bon sens.
• Le compte chez le bureau d’enregistrement. Qui prend la main sur ce compte remplace les serveurs de noms et l’enregistrement DS (Delegation Signer), et signe sa propre zone de façon parfaitement valide.

Enregistrements DNSKEY, RRSIG, DS, NSEC et NSEC3 : le rôle de chacun

DNSSEC est défini par les RFC 4033, 4034 et 4035 (2005), complétées par la RFC 5155 pour NSEC3. Il ajoute quatre familles d’enregistrements.

• DNSKEY (DNS Public Key) publie les clés publiques de la zone. Le champ flags vaut 257 pour une clé marquée SEP (Secure Entry Point), conventionnellement la KSK (Key Signing Key), et 256 pour une ZSK (Zone Signing Key).
• RRSIG (Resource Record Signature) porte la signature d’un RRset (Resource Record Set, l’ensemble des enregistrements de même nom et même type). Il contient l’algorithme, le key tag de la clé signataire, une date de début et une date d’expiration absolues. On signe un RRset entier, jamais un enregistrement isolé.
• DS (Delegation Signer) est publié dans la zone parente et contient une empreinte de la KSK de la zone fille. C’est le seul maillon qui traverse la frontière entre deux organisations.
• NSEC (Next Secure) et NSEC3 prouvent la non-existence : un nom absent ne peut pas porter de signature, donc la zone signe à la place un intervalle (« entre alpha et delta, il n’existe rien »).

La séparation KSK/ZSK est un choix d’exploitation, pas une exigence du protocole. La KSK ne signe que le RRset DNSKEY ; la ZSK signe tout le reste. Changer la ZSK reste interne à la zone, changer la KSK impose de modifier le DS chez le parent. Avec ECDSA (Elliptic Curve Digital Signature Algorithm) et des clés gérées par un signeur automatique, une CSK (Combined Signing Key) unique est un choix défendable : une seule clé, un seul roulement, mais chaque roulement passe alors par le parent.

NSEC contre NSEC3. NSEC chaîne les noms en clair : suivre la chaîne énumère toute la zone en quelques requêtes (zone walking). NSEC3 remplace les noms par des empreintes SHA-1 (Secure Hash Algorithm 1) salées et itérées, ce qui ne fait que déplacer le problème : les empreintes collectées se cassent hors ligne par dictionnaire, et les noms d’hôtes ne sont pas des mots de passe à haute entropie. La RFC 9276 recommande désormais zéro itération supplémentaire et pas de sel, car les itérations coûtent surtout aux résolveurs (un validateur reçoit plusieurs NSEC3 par réponse négative). Position à tenir : NSEC3 avec opt-out pour les grandes zones de délégation comme les TLD (Top-Level Domain) ; pour une zone d’entreprise, considérer que le contenu public d’une zone DNS est public, et ne pas y ranger ce qui ne doit pas l’être. Les serveurs qui signent à la volée peuvent aussi produire des preuves de non-existence minimales, qui ne révèlent aucun nom voisin.

Chaîne de confiance DNSSEC : de la racine au registre et à la zone

Un résolveur validant ne connaît qu’une clé a priori : l’ancre de confiance, la KSK de la racine. Tout le reste se déduit, maillon par maillon. Le schéma se lit de haut en bas : chaque zone signe l’empreinte (DS) de la clé de sa fille, puis la clé de la fille signe ses propres enregistrements.

La racine. Signée depuis juillet 2010. Les opérations de la KSK racine ont lieu lors de cérémonies trimestrielles, organisées par l’IANA (Internet Assigned Numbers Authority), fonction opérée par l’ICANN (Internet Corporation for Assigned Names and Numbers), dans deux installations sécurisées aux États-Unis. La clé privée vit dans des HSM (Hardware Security Module) ; leur activation exige la présence de plusieurs représentants de la communauté détenteurs de cartes. Les cérémonies sont filmées, scriptées et publiées. La cérémonie produit des signatures du RRset DNSKEY racine pour les trimestres suivants ; la ZSK, elle, signe la zone au quotidien.

Le roulement de 2018. Le 11 octobre 2018, la racine est passée de la KSK-2010 à la KSK-2017, après un an de report : les mesures montraient qu’une part non négligeable de résolveurs ne connaissait pas la nouvelle clé. La mise à jour automatique des ancres (RFC 5011) existait pourtant ; elle suppose qu’un résolveur tourne en continu pendant la période de publication et puisse écrire son fichier d’ancres, deux conditions que des images figées, des conteneurs recréés à chaque déploiement et des appliances jamais mises à jour ne remplissent pas. Un second roulement, vers une KSK générée en 2024, a été engagé par l’ICANN ; son calendrier et son état se vérifient sur le site de l’IANA. La leçon reste la même : une ancre de confiance codée en dur dans une image est une panne à date différée.

Registre et bureau d’enregistrement. Le DS d’une zone se publie dans la zone du TLD, opérée par le registre. Le titulaire n’y a pas accès directement : il transmet le DS (ou le DNSKEY) à son bureau d’enregistrement, qui le pousse au registre via EPP (Extensible Provisioning Protocol). Ce chemin est la faiblesse opérationnelle de DNSSEC : interface web, ticket, délai, parfois un champ « algorithme » mal saisi. Les enregistrements CDS (Child DS) et CDNSKEY (RFC 7344 et RFC 8078) permettent à la zone fille de signaler elle-même le DS attendu ; le parent qui les lit met le DS à jour sans intervention humaine. Le support dépend du registre et du bureau d’enregistrement ; quand il existe, l’activer supprime l’étape la plus fragile du roulement de KSK.

Le compromis central se lit ici. On gagne une authenticité de bout en bout entre la zone et le résolveur, vérifiable sans aucune autorité de certification commerciale ; on paie une dépendance stricte à une chaîne d’acteurs (racine, registre, bureau d’enregistrement, signeur) et à des horloges, où toute incohérence se traduit non par une alerte mais par une zone injoignable.

Validation DNSSEC par le résolveur : validée, bogus, non signée

Le résolveur validant classe chaque réponse dans l’un de trois états, et c’est cette classification qui décide de ce que le client reçoit.

Le point délicat est le cas « non signé ». Une zone sans DS est acceptée sans validation, à condition que l’absence de DS soit elle-même prouvée par une réponse signée de la zone parente. Un attaquant ne peut donc pas supprimer le DS en route pour rétrograder une zone signée. Il peut en revanche le supprimer au registre, avec le compte du bureau d’enregistrement.

Une réponse bogus produit un SERVFAIL (code d’échec du serveur), indistinguable d’une panne de serveur pour le client. Les erreurs DNS étendues, dites EDE (Extended DNS Errors, RFC 8914), précisent la cause quand le résolveur les émet : code 6 « DNSSEC Bogus », 7 « Signature Expired », 9 « DNSKEY Missing », 10 « RRSIGs Missing ». Le drapeau CD (Checking Disabled) demande au résolveur de répondre sans valider ; comparer une requête avec et sans CD est le premier réflexe de diagnostic.

Pourquoi le client fait confiance au résolveur. Le résolveur stub d’un système d’exploitation ne valide pas : il lit le drapeau AD (Authenticated Data) positionné par le résolveur. Ce drapeau n’est qu’un bit dans un paquet non authentifié. Il n’a de valeur que si le canal entre client et résolveur est de confiance : résolveur sur la même machine, ou liaison protégée par DoT ou DoH vers un résolveur qu’on contrôle. Pointer un parc vers un résolveur validant interne puis laisser le trafic DNS traverser en clair un Wi-Fi invité, c’est blinder la porte du coffre et confier la combinaison à un mégaphone. Les applications qui doivent s’appuyer sur DNSSEC (DANE en tête) exigent un validateur local ou un canal authentifié.

Exemple : vérifier une chaîne DNSSEC avec dig et delv

Les commandes suivantes utilisent dig et delv (distribués avec BIND 9) et des noms réels : example.com est signé, dnssec-failed.org est volontairement cassé pour les tests. Le résolveur interrogé doit valider.

# 1. Réponse avec ses signatures ; vérifier "flags: ... ad" dans l'en-tête
dig +dnssec www.example.com A

# 2. Clés de la zone : flags 257 (KSK) et 256 (ZSK), algorithme, key tag
dig +dnssec +multi example.com DNSKEY

# 3. Empreinte publiée chez le parent : son key tag doit correspondre à une clé 257
dig +multi example.com DS

# 4. Validation de bout en bout effectuée localement par delv,
#    sans faire confiance au drapeau AD du résolveur
delv www.example.com A

# 5. Zone cassée : SERVFAIL avec validation...
dig dnssec-failed.org A
# ...et réponse obtenue en désactivant la validation (drapeau CD)
dig +cd dnssec-failed.org A

Lecture : si la requête 5 renvoie SERVFAIL et la variante +cd une adresse, le résolveur valide correctement. Si les deux renvoient une adresse, le résolveur ne valide pas, quoi qu’en dise sa documentation. Pour une zone en production, la sortie de la commande 2 montre aussi les dates d’expiration des RRSIG, à surveiller (voir plus bas). Pour une vue graphique de la chaîne, DNSViz affiche chaque maillon et signale les incohérences entre DS et DNSKEY.

Exploitation DNSSEC : algorithmes, roulement des clés, expiration des signatures

Prérequis avant de signer. Un serveur faisant autorité qui gère la signature automatique (BIND 9.16 et suivants avec dnssec-policy, Knot DNS, PowerDNS), des horloges synchronisées en NTP (Network Time Protocol) sur signeurs et résolveurs, un bureau d’enregistrement qui accepte les DS pour l’algorithme choisi (idéalement CDS/CDNSKEY), des réseaux qui laissent passer EDNS (Extension Mechanisms for DNS) et le repli en TCP sur le port 53. Un pare-feu qui bloque le DNS en TCP ou les fragments UDP fait échouer les réponses DNSSEC volumineuses ; la taille de tampon EDNS de 1232 octets, recommandée depuis le DNS Flag Day 2020, évite la fragmentation au prix d’un repli TCP plus fréquent.

Algorithmes. Choisir ECDSA P-256 avec SHA-256 (algorithme 13) par défaut, Ed25519 (algorithme 15) si toute la chaîne d’outils et les résolveurs ciblés le prennent en charge. La RFC 8624 déconseille de signer avec RSA/SHA-1 (algorithmes 5 et 7) : aucune nouvelle zone ne devrait les employer. RSA (Rivest-Shamir-Adleman) avec SHA-256 (algorithme 8) reste valide mais produit des clés et signatures bien plus grosses, donc des réponses plus lourdes et plus amplifiables. Pour le DS, utiliser l’empreinte SHA-256 (type 2) ; le type 1 (SHA-1) n’a plus de raison d’être. Le détail du compromis entre courbes et RSA est traité dans Signature : courbes elliptiques ou RSA.

Roulement des clés. La RFC 7583 décrit les méthodes. Pour la ZSK : pré-publication (nouvelle clé publiée dans le DNSKEY, attente d’au moins le TTL du RRset DNSKEY, bascule de la signature, attente du TTL maximal des données signées, retrait). Pour la KSK : double DS ou double signature, avec une attente obligatoire sur le TTL du DS chez le parent, que la zone ne contrôle pas. Retirer l’ancienne KSK avant que l’ancien DS ait expiré des caches casse la validation pour tous les résolveurs qui l’ont encore. La règle générale : chaque étape d’un roulement attend l’expiration du TTL de l’étape précédente, et le TTL qui compte est souvent celui de quelqu’un d’autre. Changer d’algorithme est un cas à part, plus long, qui exige des signatures dans les deux algorithmes pendant la transition.

Expiration des signatures. C’est la panne DNSSEC classique, et elle est sournoise : tout fonctionne jusqu’à la date d’expiration du RRSIG, puis la zone entière disparaît pour les résolveurs validants, tandis qu’elle répond parfaitement à un dig sans validation. Causes typiques : re-signature manuelle oubliée, signeur arrêté, transfert de zone bloqué vers les secondaires qui servent donc d’anciennes signatures, horloge dérivée. La signature doit être automatique, avec une fenêtre de validité de plusieurs jours à plusieurs semaines et une re-signature bien avant l’échéance. Signer à la main avec une tâche planifiée, c’est réinventer le certificat qui expire un dimanche, mais pour toute la zone d’un coup.

Clés privées. Une KSK compromise permet de signer n’importe quoi dans la zone jusqu’au retrait du DS. Les signeurs majeurs savent stocker les clés dans un HSM via PKCS#11 (Public-Key Cryptography Standards #11) ; voir Module cryptographique matériel et PKCS#11. La sauvegarde des clés privées est obligatoire : perdre la KSK sans sauvegarde oblige à retirer le DS, donc à repasser la zone en non signée le temps de la transition. La restauration se teste, comme toute sauvegarde.

Supervision. Surveiller au minimum : la marge restante avant expiration des RRSIG sur chaque serveur faisant autorité (primaires et secondaires), la cohérence entre le DS publié chez le parent et les DNSKEY de la zone, l’égalité des numéros de série entre serveurs, le résultat d’une validation complète (delv, ou dnssec-verify et ldns-verify-zone sur le fichier de zone) depuis plusieurs résolveurs. Alerter à plusieurs jours de l’échéance, pas à l’échéance.

Surface d’attaque de DNSSEC et contre-mesures

• Amplification. Les réponses signées (DNSKEY, ANY) sont volumineuses et servent de vecteur d’attaque par réflexion. Contre-mesures : limitation de débit des réponses, dite RRL (Response Rate Limiting), sur les serveurs faisant autorité, réponses minimales à ANY (RFC 8482), algorithmes elliptiques.
• Déni de service des validateurs. La vulnérabilité KeyTrap (CVE-2023-50387) exploitait des zones construites avec de nombreuses clés et signatures en collision de key tag pour épuiser le processeur des résolveurs ; une variante visait le calcul des itérations NSEC3 (CVE-2023-50868). Contre-mesure : résolveurs à jour, qui plafonnent désormais le travail de validation par réponse.
• Énumération de zone. Voir NSEC/NSEC3 plus haut ; la contre-mesure réelle est de ne rien publier de sensible dans le DNS public.
• Compromission du bureau d’enregistrement. Hors de portée de DNSSEC. Contre-mesures : authentification forte sur le compte, verrouillage au registre (registry lock) quand il est proposé, surveillance du DS et des serveurs de noms publiés.
• Rétrogradation par algorithme. Un validateur qui ne connaît pas un algorithme traite la zone comme non signée. Choisir un algorithme largement implémenté évite que la protection disparaisse silencieusement pour une partie des clients.

DANE : ce que DNSSEC rend possible ensuite

Une fois la zone signée, DANE (DNS-based Authentication of Named Entities, RFC 6698) publie dans un enregistrement TLSA (TLS Authentication) l’empreinte du certificat ou de la clé attendus sur un service. Le client TLS (Transport Layer Security) compare le certificat présenté à cette empreinte, ce qui peut restreindre ou remplacer la confiance accordée aux autorités de certification.

Le seul déploiement massif est SMTP (Simple Mail Transfer Protocol) entre serveurs de messagerie (RFC 7672), où DANE résout un vrai problème : sans lui, STARTTLS se rétrograde trivialement. Les navigateurs, eux, n’implémentent pas DANE ; pour le web, la confiance reste celle des magasins de certificats et de Certificate Transparency. Point d’exploitation : un enregistrement TLSA qui ne suit pas le renouvellement du certificat coupe la messagerie entrante. Publier l’empreinte de la clé publique (sélecteur SPKI (Subject Public Key Info)) plutôt que du certificat, et réutiliser la clé lors du renouvellement, ou publier la nouvelle empreinte avant la bascule. Le lien entre DNS et identité TLS est développé dans Méthodes de validation de domaine.

Pour le reste du socle réseau, voir DNS, DHCP, NTP : services d’infrastructure réseau ; l’opinion du site sur le DNS se trouve dans l’éditorial Le DNS, le protocole qu’on ne regarde jamais.

🐝 Ce qui arrive si on s’en passe

Sans zone signée ni résolveur validant, aucun signal ne distingue une réponse forgée qui gagne la course d’une réponse légitime : pas de SERVFAIL, pas de code EDE, aucune trace dans les journaux du résolveur. L’empoisonnement n’est donc ni détecté sur le moment ni reconstituable après coup. Les enregistrements qui servent d’ancrage à d’autres mécanismes deviennent falsifiables au même titre qu’une adresse. La clé DKIM publiée en TXT peut être remplacée pour qu’un message usurpé passe la vérification chez un destinataire dont le résolveur est empoisonné. L’enregistrement CAA (Certification Authority Authorization, qui désigne les autorités autorisées à émettre) peut être masqué par une réponse vide forgée. Une autorité de certification dont le résolveur est empoisonné valide le domaine au profit de l’attaquant, qui obtient un certificat authentique. Enfin, OpenSSH n’accorde pas de confiance automatique aux empreintes SSHFP (empreintes de clés d’hôte SSH publiées dans le DNS) sans drapeau AD : la vérification de la clé d’hôte repose alors sur la confiance au premier usage.

🦫 Explication de la marmotte 🍫

Quand un ordinateur veut joindre un site, il demande à un serveur spécialisé, le résolveur, de traduire le nom du site en adresse numérique. Le résolveur interroge d’autres serveurs, puis garde la réponse en mémoire pour la redonner à tout le monde. Problème : un pirate peut envoyer une fausse réponse plus vite que la vraie, et le résolveur la croit. Tous les utilisateurs sont alors envoyés vers une mauvaise adresse.

DNSSEC ajoute une signature numérique à chaque réponse. Le propriétaire d’un nom possède une clé secrète qui fabrique les signatures, et publie la clé publique qui permet de les vérifier. Pour savoir que cette clé publique est la bonne, le niveau au-dessus (par exemple le gestionnaire de « .fr ») publie une empreinte de cette clé et la signe lui-même. Et ainsi de suite jusqu’au sommet, la racine, dont le résolveur connaît la clé à l’avance.

Le résolveur vérifie chaque maillon. Si tout est correct, il répond. Si une signature est fausse ou périmée, il refuse et renvoie une erreur : le site devient injoignable. C’est pourquoi les signatures doivent être renouvelées automatiquement avant leur date limite, et les clés changées en respectant des délais d’attente.

DNSSEC ne cache pas les questions posées, ne protège pas le trajet entre le résolveur et l’ordinateur, et n’empêche pas un voleur du compte de gestion du nom de tout remplacer.

À lire aussi

• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défenseComparaison de DNSSEC, DoT, DoH, DoQ et ODoH, ce que chacun protège et contre qui, ce que la résolution chiffrée retire à la détection et comment la défense reprend la main.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• Protocole SSH, clés d'hôte, authentification et durcissementFonctionnement du protocole SSH-2, confiance dans la clé d'hôte, authentification des utilisateurs, redirections, incidents connus et durcissement d'OpenSSH.
• IPv4, CIDR et plans d’adressageApprendre à lire, calculer et concevoir un adressage IPv4 cohérent pour LAN, DMZ, VPN, cloud, laboratoires et environnements multi-sites.

Pages voisines

La citent

• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

DNSSEC : chaîne de confiance, validation et exploitation des clés

Elle cite

• ⇄Lien dans les deux sens :Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades
• ⇄Lien dans les deux sens :Le DNS, le protocole qu'on ne regarde jamais
• ⇄Lien dans les deux sens :STARTTLS : attaque par retrait, MTA-STS et TLS implicite
• DNS over TLS (DoT) : chiffrer la résolution de noms
• DNS, DHCP, NTP : services d'infrastructure réseau
• Choisir ECDSA, EdDSA ou RSA pour un certificat TLS
• Déployer SPF DKIM DMARC jusqu'à reject
• Sécuriser la validation de domaine HTTP-01 et DNS-01
• Surveiller Certificate Transparency pour son domaine

⇄ : les deux pages se citent l’une l’autre.