DNSSEC ajoute au DNS une preuve cryptographique d'origine et d'intégrité. Pour le comprendre, il faut toutefois séparer deux métiers souvent cachés derrière l'expression « serveur DNS » : publier une zone et résoudre les noms pour des clients. BIND9, Unbound et dnsmasq ne prennent pas naturellement la même place dans cette chaîne.

DNSSEC n'est pas nouveau : ses RFC de base datent de mars 2005 et la racine du DNS est signée depuis le 15 juillet 2010. L'actualité de 2026 est le prochain changement de KSK de la racine, programmé par l'IANA le 11 octobre 2026.

Ce billet part des rôles de chaque serveur, construit la chaîne de confiance, puis entre dans les clés KSK et ZSK, leur rotation et les erreurs capables de rendre un domaine invisible aux résolveurs validants.

Avant DNSSEC : quel serveur DNS fait quoi ?

Une requête traverse normalement plusieurs rôles :

  • le stub resolver du poste transmet la question à un serveur configuré ;
  • le résolveur récursif avec cache cherche la réponse et la conserve pendant son TTL ;
  • les serveurs autoritatifs publient les données officielles de chaque zone ;
  • avec DNSSEC, un validateur vérifie les signatures et la chaîne allant d'une ancre de confiance jusqu'à la réponse.
Logiciel Rôle naturel DNSSEC Usage typique
BIND9 Serveur autoritatif complet ou résolveur récursif/cache Signe des zones et sait valider les réponses DNS public d'un domaine, DNS d'entreprise ou résolveur dédié
Unbound Résolveur récursif, cache et validateur Validation DNSSEC au cœur de sa conception Résolution sécurisée pour un réseau, un serveur ou derrière un filtre local
dnsmasq Redirecteur/cache léger, DNS local et souvent DHCP Peut valider s'il a été compilé avec le support et dispose d'ancres de confiance Box, petit LAN, laboratoire, conteneurs ou noms locaux

BIND9 est le plus polyvalent, mais cela ne signifie pas qu'une même instance doive tout faire. Séparer le serveur autoritatif public du résolveur récursif limite les risques et évite de transformer le premier en résolveur ouvert, exploitable dans des attaques par amplification.

Unbound n'est pas, en règle générale, le serveur choisi pour publier une zone publique complète. Il excelle à interroger la hiérarchie, mettre en cache et valider. dnsmasq est encore plus léger : il apporte des noms locaux et du DHCP, puis transmet généralement les questions à Unbound, BIND ou un résolveur externe.

flowchart LR
    A["Postes du réseau"] --> B["dnsmasq facultatif<br>noms locaux, DHCP, cache"]
    B --> C["Unbound ou BIND récursif<br>cache et validation DNSSEC"]
    C --> D["Racine signée"]
    C --> E["Zone de premier niveau<br>.fr, .com..."]
    C --> F["BIND9 ou service autoritatif<br>zone du domaine signée"]
    F -->|"DNSKEY, RRSIG,<br>A, MX, TXT, TLSA"| C

Dans une petite architecture, le chemin peut être clients → dnsmasq → Unbound. BIND9 peut remplacer Unbound comme résolveur validant. Pour un poste isolé, Unbound peut aussi écouter directement en local sans dnsmasq.

Pourquoi le DNS historique avait besoin de signatures

Le DNS a été conçu comme une base distribuée, performante et tolérante au cache. Les spécifications classiques ne donnent cependant pas au client une preuve cryptographique que la réponse reçue vient bien de l'autorité attendue. Une réponse falsifiée injectée dans un cache peut rediriger un nom vers une autre adresse, un autre serveur de courrier ou une fausse clé publiée en TXT.

DNSSEC a connu plusieurs étapes avant que les RFC 4033, 4034 et 4035 ne définissent en 2005 l'architecture actuelle. La signature de la zone racine en juillet 2010 a permis de construire une chaîne mondiale à partir d'une ancre de confiance commune. Le premier remplacement de la KSK racine a ensuite eu lieu en 2018.

DNSSEC apporte trois propriétés :

  1. authentification de l'origine des données : la réponse est rattachée à la zone qui l'a signée ;
  2. intégrité : une modification des données signées est détectable ;
  3. preuve authentifiée de non-existence : NSEC ou NSEC3 permet de prouver qu'un nom ou un type d'enregistrement n'existe pas.

DNSSEC ne fournit en revanche :

  • ni confidentialité — les requêtes et réponses restent lisibles sans DoT, DoH ou autre tunnel chiffré ;
  • ni protection contre un serveur autoritatif lui-même compromis ;
  • ni garantie qu'une adresse IP, un site ou un message est sans danger ;
  • ni certificat HTTPS, ni chiffrement du courrier électronique.

Une réponse DNSSEC valide signifie « cette donnée est bien celle publiée par la zone », pas « cette donnée est honnête ».

Les quatre enregistrements à connaître

DNSSEC ne signe pas chaque ligne indépendamment. Il signe un RRset, c'est-à-dire l'ensemble des enregistrements d'un même nom et d'un même type.

Enregistrement Rôle
DNSKEY Publie la partie publique d'une clé de la zone
RRSIG Porte la signature d'un RRset, avec son algorithme et ses dates de validité
DS Dans la zone parente, désigne par empreinte une clé de la zone enfant
NSEC ou NSEC3 Prouve de manière signée qu'un nom ou un type n'existe pas

Les clés privées restent sur le système de signature. Le DNS public ne reçoit que les DNSKEY, les signatures et les preuves nécessaires à la validation.

Un exemple volontairement abrégé ressemble à ceci :

example.com. IN DNSKEY 257 3 13 BASE64_CLE_PUBLIQUE_KSK
example.com. IN DNSKEY 256 3 13 BASE64_CLE_PUBLIQUE_ZSK
example.com. IN RRSIG DNSKEY 13 2 3600 ...
example.com. IN DS 12345 13 2 EMPREINTE_SHA256

Les valeurs sont illustratives et ne doivent pas être copiées. Dans un vrai enregistrement DNSKEY, 3 désigne le protocole DNSSEC et 13 l'algorithme ECDSAP256SHA256. Le DS est publié par le parent — souvent via le bureau d'enregistrement — et non simplement ajouté dans le fichier de la zone enfant.

La chaîne de confiance, de la racine au domaine

Un validateur possède une ancre de confiance, normalement la KSK publique de la racine. Il vérifie ensuite chaque délégation :

flowchart TD
    A["Ancre de confiance<br>DNSKEY de la racine"] --> B["RRSIG du DNSKEY racine"]
    B --> C["DS de .fr publié dans la racine"]
    C --> D["DNSKEY et signatures de .fr"]
    D --> E["DS de example.fr publié dans .fr"]
    E --> F["DNSKEY et signatures de example.fr"]
    F --> G["RRset final<br>A, AAAA, MX, TXT ou TLSA"]

Le principe peut se résumer ainsi :

ancre de confiance → DNSKEY parent → DS enfant → DNSKEY enfant → RRSIG des données

Le parent ne stocke pas la clé privée ni toutes les clés de l'enfant. Il publie un DS, une empreinte qui permet de reconnaître une clé de l'enfant. Cette étape relie les deux zones.

KSK et ZSK : deux fonctions, pas deux espèces de clés

La séparation KSK/ZSK est une convention d'exploitation. Pour le protocole, ce sont des enregistrements DNSKEY capables de vérifier des signatures. C'est l'outil de signature qui leur attribue des rôles différents.

  • La Zone Signing Key (ZSK) signe les RRsets ordinaires de la zone : A, AAAA, MX, TXT, TLSA, ainsi que les preuves NSEC/NSEC3. Elle ne signe généralement pas le RRset DNSKEY.
  • La Key Signing Key (KSK) signe le RRset DNSKEY. Le DS publié chez le parent pointe généralement vers cette clé.
  • Une Combined Signing Key (CSK) ou clé à rôle unique signe à la fois le RRset DNSKEY et les autres données.
Point ZSK KSK
Données signées RRsets ordinaires de la zone RRset DNSKEY
Interaction avec le parent lors d'un changement Normalement aucune Oui lorsque le DS doit changer
Exposition Souvent disponible au signataire en continu Peut être mieux isolée ou protégée par HSM
Rotation Opération locale, donc plus simple Coordination des caches, du parent et parfois des ancres
Drapeau DNSKEY courant 256 257 avec le bit SEP

Le drapeau 257 est une indication de Secure Entry Point, pas une règle qui obligerait tous les validateurs à traiter cette clé comme une KSK. De même, une clé à 256 est couramment une ZSK, mais le rôle réel dépend de ce qui a été signé.

Pourquoi les séparer ?

Historiquement, la ZSK signe beaucoup plus souvent et peut être renouvelée sans contacter le parent. La KSK signe peu de données mais son remplacement exige une modification du DS. On peut donc garder la KSK dans un environnement plus protégé et utiliser une ZSK plus opérationnelle.

Avec l'automatisation moderne, un algorithme compact et un hébergeur DNS géré, une CSK peut être plus simple et tout à fait valable. La séparation n'est pas automatiquement « plus sécurisée » : elle ajoute aussi deux clés, deux cycles et davantage d'occasions de se tromper. Il faut suivre la politique du véritable opérateur de zone plutôt que recopier un schéma ancien.

Signer une zone avec BIND9

BIND9 peut publier une zone signée et gérer automatiquement les signatures et renouvellements. Une structure minimale moderne ressemble à ceci :

options {
    directory "/var/cache/bind";
    recursion no;
};

zone "example.com" {
    type primary;
    file "/etc/bind/db.example.com";
    dnssec-policy default;
    inline-signing yes;
};

recursion no correspond ici à une instance autoritative publique. dnssec-policy default demande à BIND de générer et maintenir les clés selon sa politique, tandis que l'inline signing conserve une version signée servie aux clients.

Ce bloc n'achève pas le déploiement. Il reste notamment à :

  1. vérifier que la zone signée publie bien DNSKEY, RRSIG et NSEC/NSEC3 ;
  2. récupérer le DS correspondant à la clé choisie par la politique ;
  3. transmettre ce DS au bureau d'enregistrement ou au gestionnaire de la zone parente ;
  4. attendre la propagation puis valider la chaîne depuis l'extérieur ;
  5. superviser les expirations de signatures, l'état des clés et les futurs renouvellements.

Les détails de dnssec-policy, des chemins et de l'automatisation dépendent de la version de BIND9 et de la distribution. Les fichiers de clés et d'état doivent être accessibles au processus named, protégés contre la lecture non autorisée et inclus dans une stratégie de sauvegarde cohérente.

Signer la zone sans publier le bon DS chez le parent crée une île signée mais non reliée. Publier un DS incorrect est pire : la zone devient bogus et les validateurs répondent généralement SERVFAIL.

Valider avec BIND9, Unbound ou dnsmasq

La signature est produite côté autoritatif ; la validation se déroule côté résolveur récursif.

BIND9 comme résolveur validant

Sur une instance récursive réservée au réseau de confiance :

options {
    recursion yes;
    allow-recursion { 127.0.0.1; 192.0.2.0/24; };
    dnssec-validation auto;
};

Dans les versions récentes, dnssec-validation auto est le comportement par défaut. BIND utilise l'ancre de confiance racine fournie et la maintient automatiquement. La règle allow-recursion est essentielle : un résolveur récursif exposé à tout Internet devient une ressource pour les attaquants.

Unbound comme résolveur validant

Unbound est un choix naturel lorsque l'on veut uniquement récursion, cache et validation. Sa configuration s'appuie sur un fichier d'ancre racine maintenu automatiquement :

server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    auto-trust-anchor-file: "/chemin/gere/vers/root.key"

Le chemin réel dépend du paquet. unbound-anchor initialise ou met à jour cette ancre ; sur une distribution, il faut de préférence utiliser le mécanisme fourni par le paquet et le service plutôt que déposer manuellement une ancienne clé.

dnsmasq devant Unbound

dnsmasq est pratique pour associer le DNS local au DHCP, mettre de petites réponses en cache et transmettre le reste :

server=127.0.0.1#5335
domain-needed
bogus-priv

Dans ce schéma, Unbound écoute sur le port local 5335 et effectue la récursion ainsi que la validation DNSSEC. dnsmasq reste la façade du LAN. Il faut décider clairement quel composant valide et comment le résultat est transmis ; empiler deux validations sans comprendre les drapeaux DO, CD et AD complique le diagnostic.

dnsmasq sait aussi valider lui-même avec l'option dnssec, à condition que le binaire ait été compilé avec ce support, que les serveurs amont fournissent les données DNSSEC et qu'une ancre de confiance actuelle soit configurée. En 2026, il ne faut surtout pas coller pour toujours une ancienne KSK racine dans un fichier : l'ancre doit suivre le rollover programmé.

Tester réellement la validation

# Voir les clés et demander les signatures associées
dig +dnssec example.com DNSKEY

# Voir une réponse et ses données DNSSEC
dig +dnssec example.com A

# Interroger la délégation publiée par le parent
dig example.com DS

# Effectuer une validation complète avec les outils BIND
delv example.com A

Quelques pièges de lecture :

  • dig +dnssec demande les données DNSSEC ; leur présence ne prouve pas à elle seule que toute la chaîne est valide.
  • Le drapeau ad signifie Authenticated Data lorsque la réponse vient d'un résolveur validant. Il n'est digne de confiance que si le chemin entre le client et ce résolveur est lui-même maîtrisé.
  • delv effectue la validation et fournit un diagnostic plus utile qu'une simple présence de RRSIG.
  • Une horloge système incorrecte peut faire paraître une signature pas encore valide ou déjà expirée.

Renouveler les clés sans casser la zone

Une clé n'est pas éternelle. Le rollover consiste à introduire une nouvelle clé tout en laissant aux anciennes données le temps de disparaître des caches.

Rotation d'une ZSK

Une méthode de prépublication suit ce principe :

  1. publier la nouvelle DNSKEY sans encore l'utiliser ;
  2. attendre que les caches aient pu l'apprendre ;
  3. signer les nouveaux RRsets avec la nouvelle ZSK ;
  4. conserver l'ancienne clé tant que ses signatures peuvent encore être en cache ;
  5. retirer ensuite les anciennes signatures et l'ancienne clé.

La rotation reste interne à la zone, car le DS parent vise normalement la KSK.

Rotation d'une KSK

Le changement d'une KSK ajoute la coordination avec le parent :

  1. publier la nouvelle KSK dans le RRset DNSKEY ;
  2. signer de façon à maintenir une chaîne valide avec l'ancienne et la nouvelle situation ;
  3. faire publier le nouveau DS par le parent ;
  4. attendre les TTL du DS, des DNSKEY et des signatures ;
  5. vérifier la nouvelle chaîne depuis plusieurs validateurs ;
  6. retirer l'ancien DS, puis l'ancienne clé seulement lorsque les caches ne peuvent plus en dépendre.

L'ordre exact varie selon la méthode — double DS, double signature ou automatisation du fournisseur. Retirer l'ancienne KSK avant que le nouveau DS soit utilisable brise la chaîne.

Le rollover de la racine en 2026

L'IANA a publié la KSK successeure dans la zone racine le 11 janvier 2025. Elle doit commencer à signer la racine le 11 octobre 2026. Les résolveurs qui maintiennent automatiquement leur ancre de confiance ont donc une longue période pour apprendre la nouvelle clé. Les installations figées avec une clé copiée à la main doivent être auditées avant cette date.

Les pannes DNSSEC les plus courantes

Situation État vu par un validateur Conséquence
Zone non signée et aucun DS insecure Résolution classique, sans preuve DNSSEC
Zone signée mais aucun DS chez le parent insecure Signatures présentes, mais aucune chaîne depuis la racine
DS publié mais mauvaise DNSKEY bogus Généralement SERVFAIL
RRSIG expirée ou pas encore valide bogus Domaine indisponible pour les clients du validateur
Ancienne clé retirée trop tôt bogus selon les caches Panne intermittente difficile à reproduire
Secondaire non synchronisé Réponses variables Certains serveurs répondent avec une zone ou des signatures obsolètes
Paquets DNSSEC trop grands bloqués Timeout ou repli défaillant Résolution lente ou impossible ; UDP, fragmentation et TCP doivent être testés

Une panne DNSSEC est souvent perçue comme une panne DNS ordinaire. Le navigateur ne dit pas « le DS ne correspond plus » ; il indique seulement que le nom est introuvable. La supervision doit donc tester la validation, pas uniquement la présence d'une réponse depuis le serveur autoritatif.

Ce que DNSSEC change pour le courrier électronique

Le courrier dépend fortement du DNS : MX pour choisir le serveur, SPF et DMARC dans des enregistrements TXT, clés DKIM sous _domainkey et politiques de transport. DNSSEC permet à un résolveur validant de détecter une falsification de ces réponses.

Il ne rend toutefois pas SPF, DKIM ou DMARC obligatoires et ne transforme pas un message en preuve juridique. Le fonctionnement et les limites de ces mécanismes sont détaillés dans l'histoire des protections e-mail et du contrôle sortant.

Pour le transport SMTP, DANE va plus loin : un domaine publie un enregistrement TLSA, par exemple sous _25._tcp.mail.example.com, afin que le serveur expéditeur vérifie cryptographiquement le service TLS du MX. DANE pour SMTP exige une chaîne DNSSEC valide. MTA-STS poursuit un objectif voisin avec une politique découverte en DNS puis récupérée en HTTPS ; il repose sur le Web PKI plutôt que sur une chaîne TLSA signée.

Dans une architecture complète de boîte mail, le résolveur validant protège donc les décisions DNS du MTA. Le serveur Postfix doit encore être configuré pour utiliser DANE ou MTA-STS : signer la zone ne modifie pas automatiquement son comportement SMTP.

Une méthode de déploiement raisonnable

  1. Identifier les rôles : qui héberge la zone autoritative, qui tient le registrar, quel résolveur sert les utilisateurs et où se place éventuellement dnsmasq.
  2. Vérifier le support du fournisseur : algorithmes, automatisation, renouvellement, export du DS et procédure de secours.
  3. Activer la validation récursive : sur Unbound ou BIND, avec une ancre racine automatiquement maintenue et un accès limité au réseau autorisé.
  4. Signer la zone : de préférence avec la politique automatisée du véritable opérateur autoritatif.
  5. Contrôler avant le DS : clés, signatures, dates, réponses UDP/TCP et cohérence de tous les secondaires.
  6. Publier le DS chez le parent : puis vérifier la chaîne depuis l'extérieur.
  7. Superviser : expiration des RRSIG, état des clés, cohérence du DS, journaux de validation et disponibilité.
  8. Préparer le rollover : documenter les TTL, les contacts registrar/DNS, le retour arrière et les tests.

DNSSEC récompense l'automatisation et punit les demi-configurations. Une zone non signée reste simplement non sécurisée ; une zone déclarée signée par son parent mais mal entretenue peut disparaître pour tous les utilisateurs d'un résolveur validant.

FAQ

BIND9, Unbound et dnsmasq sont-ils interchangeables ?

Non. BIND9 peut publier et signer une zone ou servir de résolveur ; Unbound est surtout un résolveur récursif validant ; dnsmasq est un cache et redirecteur léger, souvent associé au DHCP.

DNSSEC chiffre-t-il les requêtes DNS ?

Non. DNSSEC authentifie l'origine et l'intégrité des données. La confidentialité du transport relève notamment de DNS over TLS, DNS over HTTPS ou d'un réseau protégé.

Quelle est la différence entre une KSK et une ZSK ?

La ZSK signe généralement les données de la zone, tandis que la KSK signe le RRset DNSKEY et est reliée au DS du parent. Cette séparation est une convention d'exploitation ; une CSK peut remplir les deux rôles.

Une zone signée sans DS est-elle sécurisée ?

Elle contient des signatures, mais un validateur partant de la racine ne peut pas leur faire confiance. Sans DS chez le parent, elle reste une île considérée comme insecure.

DNSSEC est-il obligatoire pour SPF, DKIM et DMARC ?

Non, ces mécanismes fonctionnent sans lui. DNSSEC protège leurs réponses DNS lorsqu'elles sont validées ; il devient en revanche indispensable pour authentifier les enregistrements TLSA utilisés par DANE SMTP.