--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "fr" category: "DNS et bases techniques" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/fr/glossaire/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC extensions de sécurité du DNS Extensions du DNS qui ajoutent des signatures numériques aux réponses DNS. Ces signatures permettent à un résolveur (le serveur qui recherche les noms pour les utilisateurs) de vérifier qu'une réponse est authentique et n'a pas été modifiée en chemin. Les titulaires l'activent auprès de leur hébergeur DNS et de leur bureau d'enregistrement. DNSSEC ajoute des signatures numériques aux réponses du système de noms de domaine (DNS), afin qu'un ordinateur puisse vérifier qu'une réponse provient bien du titulaire d'un domaine et n'a pas été modifiée en chemin. DNSSEC ne cache rien et n'arrête pas toutes les attaques. Pour l'activer, le fournisseur DNS, le bureau d'enregistrement et le registre doivent travailler ensemble. ## Ce contre quoi DNSSEC protège, en termes simples Quand quelqu'un visite example.com, un résolveur recherche son adresse. Sans DNSSEC, un attaquant qui fournit au résolveur une réponse falsifiée peut envoyer les visiteurs vers le mauvais serveur. Avec DNSSEC, un résolveur qui valide vérifie la signature et rejette la falsification. Le RFC 4033 (mars 2005) définit ce qu'apporte DNSSEC : la preuve de l'origine et de l'intégrité des données DNS. DNSSEC n'apporte aucune confidentialité, les réponses restent donc lisibles, ni aucune protection contre les attaques par déni de service. Il ne couvre que les réponses DNS, pas l'hameçonnage ni la prise de contrôle d'un compte chez un bureau d'enregistrement. Le RFC 9364 (février 2023) présente DNSSEC comme la meilleure pratique actuelle pour authentifier les données DNS ; l'utiliser ou non pour un domaine relève de la décision du titulaire. ## Comment fonctionne la chaîne de confiance, de la racine à votre domaine Un résolveur qui valide part d'une clé à laquelle il fait déjà confiance : l'ancre de confiance, c'est-à-dire la clé de signature de clés (Key Signing Key) de la zone racine, publiée par l'IANA. À partir de là, il suit une chaîne : 1. La zone racine contient un enregistrement DS signé pour le .com. 2. Cet enregistrement DS correspond à une clé de la zone .com, ce qui permet au résolveur de vérifier les enregistrements du .com, dont l'enregistrement DS de example.com. 3. Cet enregistrement DS correspond à la clé de example.com, qui vérifie les enregistrements propres au domaine. Une zone signée dont la zone parente ne contient aucun enregistrement DS est un « island of security » (îlot de sécurité) : elle ne peut pas être validée à partir de la racine. Une réponse est sûre (secure) lorsque toutes les signatures sont vérifiées, non sécurisée (insecure) lorsqu'une preuve signée montre que la zone parente ne contient aucun enregistrement DS pour la zone, et invalide (bogus) lorsque des signatures attendues manquent, ont expiré ou sont inutilisables (RFC 4033). Pour une réponse invalide, le résolveur renvoie normalement une erreur, SERVFAIL (RFC 4035). ## Clés et enregistrements : KSK, ZSK, DNSKEY, DS et RRSIG - Les enregistrements **DNSKEY** publient les clés publiques d'une zone. - Les enregistrements **RRSIG** contiennent les signatures, chacune valable seulement entre une date de début et une date d'expiration. - Les enregistrements **DS** se trouvent dans la zone parente et contiennent un identifiant de clé (key tag), un numéro d'algorithme et une empreinte de la clé de la zone enfant. - La **KSK** ne signe que l'ensemble des clés de la zone, et l'enregistrement DS de la zone parente pointe vers elle. La **ZSK** signe tout le reste. Le RFC 6781 (décembre 2012) relève que les validateurs traitent les deux sortes de clés de la même façon : la distinction est opérationnelle, et certaines zones utilisent une seule clé pour les deux rôles. Prouver qu'un nom n'existe pas exige des enregistrements spécifiques. NSEC indique le nom existant suivant, ce qui permet à n'importe qui de dresser la liste complète de la zone (« zone walking »). NSEC3 (RFC 5155) hache d'abord les noms, mais révèle encore certains détails, comme la taille de la zone. ## Activer DNSSEC : le rôle du bureau d'enregistrement, du registre et du fournisseur DNS 1. Le fournisseur DNS signe la zone et publie les enregistrements DNSKEY et RRSIG. 2. Les données DS, ou les données de clé, sont transmises au bureau d'enregistrement. 3. Le bureau d'enregistrement les envoie au registre par EPP avec l'extension secDNS (RFC 5910, mai 2010), soit sous forme de données DS, soit sous forme de données de clé à partir desquelles le registre construit l'enregistrement DS. 4. Le registre publie l'enregistrement DS dans la zone du TLD. Lorsque le bureau d'enregistrement est aussi le fournisseur DNS, les étapes 1 à 3 se réduisent souvent à un seul réglage. Pour les gTLD, le contrat d'accréditation des bureaux d'enregistrement de 2013 (RAA) impose aux bureaux d'enregistrement de transmettre, selon le RFC 5910, les demandes d'ajout, de suppression ou de modification de données de clé aux registres qui prennent en charge DNSSEC. Le contrat de registre de base (approuvé le 21 janvier 2024, en vigueur en octobre 2026) impose aux registres de gTLD de signer leurs zones et d'accepter les données de clé des domaines enfants. Les règles des ccTLD diffèrent : se renseigner auprès du bureau d'enregistrement ou du registre. Il existe aussi une voie automatisée : le fournisseur DNS publie des enregistrements CDS et CDNSKEY qui indiquent ce que doit être l'enregistrement DS, et certains registres et bureaux d'enregistrement les recherchent. Le RFC 8078 (mars 2017) a ajouté un signal pour retirer DNSSEC ; le RFC 9615 (juillet 2024) permet à la zone parente de vérifier ces enregistrements par la cryptographie avant d'activer DNSSEC. ## Ce qui peut mal tourner : signatures expirées, remplacements de clés et changements de fournisseur DNS - **Signatures expirées.** Des enregistrements RRSIG non renouvelés à temps rendent les réponses invalides. - **Un enregistrement DS sans clé correspondante.** Le RFC 6781 appelle cette situation « security lameness » : le domaine échoue pour tous les résolveurs qui valident, et la correction met du temps à se diffuser. Un changement de KSK exige donc que le nouvel enregistrement DS soit dans la zone parente avant le retrait de l'ancienne clé. - **Changement de fournisseur DNS.** L'ancien opérateur contrôle les clés. La meilleure méthode est un remplacement de clés coordonné. Si l'ancien opérateur ne coopère pas, l'enregistrement DS est retiré, les serveurs de noms sont changés et, une fois ce changement diffusé, le nouvel enregistrement DS est ajouté. Entre-temps, le domaine n'est pas signé, ce que le RFC 8078 préfère à des échecs de validation. Des TTL courts aident. Les pannes se manifestent par des SERVFAIL pour les utilisateurs de résolveurs qui valident, alors que le domaine peut encore fonctionner pour tous les autres. À la racine, au 9 octobre 2026, l'ICANN prévoit de remplacer la KSK de la racine le 11 octobre 2026 : KSK-2024 (key tag 38696) prend le relais de KSK-2017 (key tag 20326), qui doit être révoquée le 11 janvier 2027 et retirée le 22 mars 2027. Cela concerne les opérateurs de résolveurs qui valident, qui ont besoin de la nouvelle ancre de confiance, et non les titulaires. ## DNSSEC et DNS chiffré : en quoi ils diffèrent DNSSEC signe les données pour que n'importe quel résolveur puisse les vérifier, mais tout reste lisible. Le DNS sur TLS (DoT) et le DNS sur HTTPS (DoH) chiffrent la liaison entre l'appareil de l'utilisateur et le résolveur, ce qui protège la vie privée, mais ne prouvent pas que les données proviennent du titulaire de la zone. Les deux se complètent. ## Sources - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## termes associés - [enregistrement DS](https://tldlog.com/fr/glossaire/enregistrement-ds/) - [enregistrement DNSKEY](https://tldlog.com/fr/glossaire/enregistrement-dnskey/) - [résolveur](https://tldlog.com/fr/glossaire/resolveur/) - [DNS](https://tldlog.com/fr/glossaire/dns/)