---
title: DNSSEC : BIND9, Unbound, dnsmasq, KSK et ZSK
source: https://synapx.fr/blog/dnssec-ksk-zsk/
date: 2026-07-14
category: Cybersécurité
site: SynapxLab
---
# DNSSEC : BIND9, Unbound, dnsmasq, KSK et ZSK
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.
```mermaid
flowchart LR
A["Postes du réseau"] --> B["dnsmasq facultatif
noms locaux, DHCP, cache"]
B --> C["Unbound ou BIND récursif
cache et validation DNSSEC"]
C --> D["Racine signée"]
C --> E["Zone de premier niveau
.fr, .com..."]
C --> F["BIND9 ou service autoritatif
zone du domaine signée"]
F -->|"DNSKEY, RRSIG,
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 :
```dns
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 :
```mermaid
flowchart TD
A["Ancre de confiance
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
A, AAAA, MX, TXT ou TLSA"]
```
Le principe peut se résumer ainsi :
```text
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 :
```conf
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 :
```conf
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 :
```conf
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 :
```ini
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
```bash
# 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](/blog/securite-email-spf-dkim-dmarc/).
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](/blog/boite-mail/), le résolveur validant protège donc les décisions DNS du MTA. Le [serveur Postfix](/blog/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.