DNSSEC : ce que c'est, à quoi ça sert et comment l'activer

TL;DRDNSSEC ajoute une signature cryptographique aux réponses DNS pour qu'un attaquant ne puisse plus détourner votre nom de domaine vers un faux serveur. Voici comment il fonctionne, ce qu'il protège vraiment, comment l'activer et le vérifier, et les erreurs qui peuvent rendre un domaine injoignable.

🌐 Le problème : le DNS croit ce qu'on lui répond#

Quand un visiteur tape l'adresse de votre site, son ordinateur ne sait pas où le trouver. Il interroge un résolveur DNS (celui de son fournisseur d'accès, de son entreprise, ou un résolveur public), qui va chercher la réponse de serveur en serveur puis la garde en mémoire, en cache, pour les demandes suivantes. Pour comprendre ce mécanisme en détail, voyez notre article qu'est-ce qu'un serveur DNS.

Le protocole DNS a été conçu dans les années 1980, pour un réseau où tout le monde se faisait confiance. Une réponse DNS classique ne porte aucune preuve de son origine : le résolveur accepte la première réponse plausible qui arrive. Un attaquant qui parvient à glisser une fausse réponse avant la vraie peut ainsi faire enregistrer dans le cache une mauvaise adresse IP pour votre domaine. Tous les utilisateurs de ce résolveur sont alors envoyés vers le serveur de l'attaquant, sans que rien ne change dans la barre d'adresse. C'est l'empoisonnement de cache (cache poisoning).

La menace n'est pas théorique : en 2008, le chercheur Dan Kaminsky a montré une technique qui rendait cet empoisonnement beaucoup plus rapide à réussir. Les éditeurs de résolveurs ont colmaté en urgence en rendant les requêtes plus difficiles à deviner, mais il s'agissait d'une parade, pas d'une preuve d'authenticité. Cette preuve, c'est DNSSEC qui l'apporte.

🌐 Qu'est-ce que DNSSEC ?#

DNSSEC (Domain Name System Security Extensions) est un ensemble d'extensions du DNS, normalisées par l'IETF dans les RFC 4033, 4034 et 4035 en 2005. Le principe tient en une phrase : chaque réponse DNS est signée par une clé cryptographique du propriétaire de la zone, et le résolveur vérifie la signature avant d'accepter la réponse.

Une fausse réponse fabriquée par un attaquant ne peut pas porter de signature valide, puisqu'il ne possède pas la clé privée. Le résolveur qui valide DNSSEC la rejette, et l'empoisonnement échoue.

Encore faut-il que le résolveur sache que la clé publique qu'il reçoit est la bonne : un attaquant pourrait aussi bien fournir sa propre clé avec ses propres signatures. D'où la pièce maîtresse du système, la chaîne de confiance.

🌐 La chaîne de confiance : de la racine à votre domaine#

Le DNS est hiérarchique : la racine délègue .fr à l'Afnic, qui délègue exemple.fr à l'hébergeur DNS choisi par son propriétaire. DNSSEC suit exactement le même chemin. Chaque zone signe ses propres données, et sa zone parente publie une empreinte de sa clé principale, l'enregistrement DS. Comme cette empreinte est elle-même signée par le parent, la confiance descend d'un étage à l'autre.

Tout en haut, le résolveur connaît d'avance la clé de la racine : elle est livrée avec le logiciel, c'est l'ancre de confiance. La racine est signée depuis 2010.

Il suffit d'un maillon manquant pour que la chaîne s'arrête : si le DS de votre domaine n'est pas publié dans .fr, les résolveurs considèrent vos réponses comme non signées et les acceptent sans vérification, comme avant DNSSEC. Si en revanche un maillon est présent mais faux, la réponse est rejetée.

🌐 Les enregistrements DNSSEC, un par un#

Activer DNSSEC ajoute dans votre zone quelques types d'enregistrements nouveaux. Vous n'avez pas à les écrire à la main : votre hébergeur DNS les génère. Mais savoir les reconnaître aide beaucoup à diagnostiquer une panne.

NSEC3 (RFC 5155) remplit le même rôle que NSEC en masquant les noms par une empreinte, ce qui rend plus difficile l'inventaire complet d'une zone. Les recommandations actuelles (RFC 9276) préconisent de le configurer sans sel et sans itérations supplémentaires, celles-ci coûtant du calcul aux résolveurs sans réel gain de sécurité. C'est le réglage que nous avons relevé sur la zone .fr elle-même.

📌 KSK et ZSK : deux clés, deux rôles#

La plupart des zones utilisent deux paires de clés :

• la KSK (Key Signing Key) ne signe que l'ensemble des clés DNSKEY de la zone. C'est son empreinte qui est publiée dans le parent sous forme de DS ;
• la ZSK (Zone Signing Key) signe tout le reste : A, AAAA, MX, TXT, etc.

Cette séparation a un intérêt pratique : on peut changer la ZSK aussi souvent que voulu sans rien demander au registre, puisque seul le DS de la KSK est publié à l'étage supérieur. Certains hébergeurs DNS utilisent une clé unique qui cumule les deux rôles (CSK, Combined Signing Key) ; le principe de la chaîne reste identique.

🌐 Ce que DNSSEC protège, et ce qu'il ne protège pas#

DNSSEC est souvent mal compris parce qu'on lui prête des fonctions qu'il n'a pas. Voici son périmètre exact.

Deux points méritent d'être soulignés.

• DNSSEC ne chiffre rien. Il garantit l'authenticité et l'intégrité des réponses, pas leur confidentialité. Les requêtes et les réponses circulent toujours en clair.
• DNSSEC n'est pas DoH ni DoT. DNS-over-TLS (RFC 7858) et DNS-over-HTTPS (RFC 8484) chiffrent la conversation entre votre appareil et votre résolveur. Ils empêchent l'espionnage sur ce trajet, mais ne prouvent pas que le résolveur a obtenu la bonne réponse. Les deux approches sont complémentaires : l'une protège le transport, l'autre le contenu des réponses.

Enfin, la vérification est faite par le résolveur, pas par votre navigateur. Les grands résolveurs publics (ceux de Cloudflare, Google ou Quad9, par exemple) valident DNSSEC ; un résolveur qui ne valide pas laisse passer les réponses comme si DNSSEC n'existait pas.

Bon à savoir. DNSSEC renforce aussi d'autres protections qui reposent sur le DNS. Les enregistrements SPF, DKIM et DMARC de votre messagerie sont publiés dans le DNS : une zone signée empêche de les falsifier en route. Si vous découvrez ces enregistrements, lisez SPF, DKIM et DMARC expliqués simplement.

🌐 Comment activer DNSSEC sur votre domaine#

L'activation se fait toujours en deux temps, chez deux acteurs qui peuvent être différents : l'hébergeur DNS (celui qui gère votre zone, désigné par les enregistrements NS) et le registrar (celui auprès de qui vous avez réservé le nom). Si vous ne savez pas qui joue quel rôle pour votre domaine, notre guide relier son nom de domaine à son hébergement explique la différence.

1. Signer la zone chez l'hébergeur DNS. Dans la plupart des interfaces, c'est un simple interrupteur « Activer DNSSEC ». L'hébergeur crée les clés, signe la zone et vous affiche l'enregistrement DS à publier (ou la clé publique DNSKEY, selon ce que demande votre registrar).
2. Publier le DS chez le registrar. Dans l'espace de gestion du domaine, rubrique DNSSEC, recopiez les valeurs fournies : identifiant de clé (key tag), algorithme, type d'empreinte et empreinte. Le registrar les transmet au registre (l'Afnic pour .fr).
3. Vérifier que la chaîne est complète, avec les commandes ci-dessous, une fois le DS visible dans la zone parente.

L'ordre compte : la zone doit être signée avant la publication du DS. Un DS publié pour une zone qui n'est pas (ou plus) signée avec la clé correspondante rend le domaine injoignable pour tous les résolveurs qui valident.

Quand votre hébergeur DNS et votre registrar sont la même société, l'étape 2 est souvent automatique. Certains registres et registrars savent aussi lire dans votre zone des enregistrements CDS ou CDNSKEY (RFC 7344 et 8078) pour mettre à jour le DS sans intervention manuelle, quand les deux côtés le prennent en charge.

🌐 Si vous gérez vos propres serveurs de noms avec BIND#

Nos serveurs de noms fonctionnent sous BIND 9.20. Depuis la version 9.16, BIND sait créer les clés, signer la zone et renouveler les signatures tout seul grâce à l'option dnssec-policy. Voici une déclaration de zone minimale ; nous l'avons validée avec named-checkconf sur BIND 9.20.29 :

// /etc/bind/named.conf.local
zone "exemple.fr" {
    type primary;
    file "/var/lib/bind/db.exemple.fr";  // répertoire inscriptible par named
    dnssec-policy default;    // politique intégrée : clé unique ECDSA P-256 (algorithme 13)
    inline-signing yes;       // BIND garde votre fichier intact et maintient une copie signée
};

Après rechargement, la commande suivante affiche l'état des clés et indique à quel moment le DS peut être publié chez le registrar :

rndc dnssec -status exemple.fr

Adaptez le chemin du fichier de zone : BIND doit pouvoir écrire à côté (fichiers de clés et journal de la version signée). Testez toujours la configuration avec named-checkconf avant tout rechargement.

🌐 Comment vérifier qu'un domaine est bien protégé#

📌 Avec dig#

La commande dig (paquet bind9-dnsutils sous Debian) interroge un résolveur et affiche les drapeaux de la réponse. L'option +dnssec demande aussi les signatures :

# Interroger un résolveur qui valide (ici 1.1.1.1) et demander les signatures
dig +dnssec exemple.fr A @1.1.1.1

# Dans la ligne « flags: », le drapeau « ad » (Authenticated Data)
# signifie : la chaîne complète a été vérifiée par le résolveur.

# Le DS est-il publié dans la zone parente ?
dig DS exemple.fr +short @1.1.1.1

# Les clés publiques de la zone (257 = KSK, 256 = ZSK)
dig DNSKEY exemple.fr +short @1.1.1.1

Pour un domaine correctement configuré, la ligne des drapeaux ressemble à ceci (relevé du 17 octobre 2026 sur afnic.fr) :

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

📌 Avec delv#

L'outil delv, livré avec BIND, refait lui-même toute la validation et dit en clair ce qu'il en conclut : fully validated (chaîne complète et valide), unsigned answer (pas de chaîne de confiance) ou un message d'erreur si une signature est fausse.

delv @1.1.1.1 exemple.fr A

🛠️ Avec un outil en ligne#

DNSViz (dnsviz.net) dessine la chaîne de confiance complète de la racine à votre domaine et colore en rouge le maillon défaillant. Zonemaster (zonemaster.fr, développé notamment par l'Afnic) teste plus largement la configuration DNS d'un domaine, DNSSEC compris. Ce sont les deux premiers réflexes en cas de doute.

📌 Ce que nous avons relevé le 17 octobre 2026#

Nous avons lancé ces commandes depuis notre serveur, en interrogeant le résolveur public 1.1.1.1, sur trois domaines aux situations différentes.

Le cas de notre propre domaine illustre bien la logique de la chaîne : signer une zone sans publier son DS ne casse rien, mais n'apporte pas encore la protection, puisque les résolveurs n'ont aucun moyen de rattacher ces signatures à la racine. C'est la publication du DS qui « branche » la zone sur la chaîne de confiance.

Le troisième cas montre l'autre face. Pour dnssec-failed.org, le résolveur renvoie une erreur et précise la raison (« DNSKEY Missing : no SEP matching the DS found »). En ajoutant l'option +cd (checking disabled), qui demande au résolveur de ne pas valider, la même requête renvoie bien une adresse IP : le domaine existe, mais un résolveur qui valide refuse de le croire.

🌐 Les risques : quand DNSSEC rend un domaine injoignable#

DNSSEC ajoute une sécurité réelle, mais aussi un nouveau mode de panne : une erreur de configuration ne se traduit pas par une protection en moins, mais par un domaine qui disparaît pour une grande partie des internautes. Les situations à surveiller sont connues.

• Expiration des signatures. Chaque RRSIG a une date de fin de validité. Si l'hébergeur DNS cesse de re-signer la zone (logiciel arrêté, erreur de configuration, disque plein), les signatures expirent et le domaine devient injoignable. Le 17 octobre 2026, les signatures de websource.fr relevées couvraient environ deux jours (signature à la volée par l'hébergeur DNS), celles de la zone .fr environ un mois : la re-signature doit être automatique et surveillée.
• Rotation de clés (rollover). Changer une KSK impose de publier le nouveau DS, d'attendre que l'ancien disparaisse des caches, puis seulement de retirer l'ancienne clé. Brûler une étape, c'est casser la chaîne. Les outils modernes (dnssec-policy de BIND, hébergeurs DNS gérés) automatisent ces délais.
• Changement d'hébergeur DNS. C'est la cause de panne la plus fréquente pour un site : on change les serveurs de noms, le nouvel hébergeur signe avec d'autres clés (ou pas du tout), mais l'ancien DS reste publié chez le registrar. La méthode prudente consiste à retirer le DS, attendre l'expiration de sa durée de cache (une heure pour les DS de .fr que nous avons interrogés), migrer, puis réactiver DNSSEC chez le nouvel hébergeur.
• Désactivation dans le mauvais ordre. Pour la même raison, on retire toujours le DS avant de désactiver la signature, jamais l'inverse.

Les grandes entreprises ne sont pas à l'abri : Slack a raconté publiquement comment sa tentative d'activation de DNSSEC, le 30 septembre 2021, a provoqué une panne d'environ 24 heures pour une petite partie de ses utilisateurs. Leur retour d'expérience détaillé figure dans les sources.

🌐 Faut-il activer DNSSEC sur votre domaine ?#

Pour la plupart des sites, la réponse est oui, à condition que la signature soit gérée automatiquement par votre hébergeur DNS. Le coût pour vous se limite alors à la publication du DS, et le principal risque à retenir est celui du changement d'hébergeur DNS.

C'est plus prudent de différer si vous gérez vous-même vos serveurs de noms sans supervision, ou si vous prévoyez de déménager votre DNS prochainement : mieux vaut activer DNSSEC une fois la migration terminée.

Dans tous les cas, DNSSEC ne remplace ni le HTTPS, ni des mots de passe solides sur votre compte registrar (un attaquant qui y accède peut modifier vos serveurs de noms et votre DS), ni la sécurité de votre serveur. C'est une brique de plus.

Chez Websource, nous hébergeons des sites et gérons leur configuration DNS au quotidien. Si vous voulez un hébergement où ces réglages sont suivis pour vous, découvrez nos offres d'hébergement web, dès 4,99 € HT/mois, ou notre accompagnement en infogérance.

❓ Questions fréquentes#

🌐 DNSSEC chiffre-t-il mes requêtes DNS ?#

Non. DNSSEC signe les réponses pour prouver leur authenticité, mais elles circulent toujours en clair. Pour chiffrer le trajet entre votre appareil et votre résolveur, il faut DNS-over-TLS (DoT) ou DNS-over-HTTPS (DoH).

🌐 DNSSEC ralentit-il mon site ?#

Les réponses signées sont plus volumineuses et le résolveur doit vérifier les signatures, mais ces réponses sont gardées en cache comme les autres. En pratique, l'effet n'est pas perceptible pour un visiteur dans la grande majorité des cas.

🌐 Comment savoir si mon domaine utilise DNSSEC ?#

Lancez dig DS votre-domaine.fr +short : une réponse vide signifie qu'aucun DS n'est publié et que la chaîne de confiance n'est pas établie. Vous pouvez aussi tester votre domaine sur DNSViz ou Zonemaster.

🌐 Que se passe-t-il si je change d'hébergeur DNS avec DNSSEC activé ?#

Si l'ancien DS reste publié alors que le nouvel hébergeur signe avec d'autres clés, ou ne signe pas, le domaine devient injoignable pour les résolveurs qui valident. Retirez le DS avant la migration, attendez l'expiration de sa durée de cache, puis réactivez DNSSEC chez le nouvel hébergeur.

📌 Quelle est la différence entre KSK et ZSK ?#

La KSK signe uniquement les clés de la zone et son empreinte est publiée chez le parent sous forme de DS. La ZSK signe tous les autres enregistrements. On peut ainsi changer la ZSK sans rien demander au registre.

Article publié le 19/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.