Qu'est-ce que DNSSEC?
DNSSEC (Domain Name System Security Extensions) ajoute des signatures numériques aux ensembles d'enregistrements DNS. Un résolveur validant peut s'appuyer sur des signatures valides et une chaîne de confiance pour authentifier les données signées et détecter les modifications non autorisées. DNSSEC ne chiffre pas les requêtes DNS ni les réponses.Comment fonctionne DNSSEC
Chaîne de confiance (exemple avec séparation des clés) :
Zone racine (.)
├── La KSK racine (ancre de confiance) signe le RRset DNSKEY de la racine
└── La ZSK racine signe les RRsets faisant autorité de la zone racine, dont le RRset DS de .com dans la zone parente
└── Le condensat du DS correspond à la KSK de .com
├── La KSK de .com signe le RRset DNSKEY de .com
└── La ZSK de .com signe les RRsets faisant autorité de .com, dont le RRset DS de example.com dans la zone parente
└── Le condensat du DS correspond à la KSK de example.com
├── La KSK de example.com signe le RRset DNSKEY de example.com
└── La ZSK de example.com signe les RRsets faisant autorité de example.com
Le résolveur valide les signatures et les condensats DS à partir de l'ancre de confiance racine
Types d'enregistrement DNSSEC
| Enregistrement | Objet | Description |
|---|---|---|
| RRSIG | Signature | Signature cryptographique pour chaque ensemble d'enregistrements |
| DNSKEY | Clé publique | Clés publiques de signature de zone (KSK et ZSK) |
| DS | Enregistrement de délégation signé | Hachage de la KSK de la zone enfant dans la zone parent |
| NSEC/NSEC3 | Refus authentifié | Preuve qu'un enregistrement n'existe pas |
Types de clés
| Clé | Objet | Fréquence de rotation |
|---|---|---|
| KSK (clé de signature des clés) | Signe les enregistrements DNSKEY | Selon la politique ; voir la note ci-dessous |
| ZSK (clé de signature de zone) | Signe les autres RRsets faisant autorité ; les RRsets NS de délégation côté parent et les enregistrements glue ne sont pas signés ([RFC 4035, section 2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Selon la politique ; voir la note ci-dessous |
La fréquence de rotation dépend du rôle de la KSK et de la politique de l'opérateur. Pour une KSK associée à un enregistrement DS dans sa zone parente, la [RFC 6781, section 3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) indique qu'un an constitue un intervalle raisonnable lorsqu'une rotation régulière est choisie. Une KSK utilisée comme ancre de confiance doit être renouvelée en coordination avec les résolveurs validateurs, et sa période d'utilisation peut être bien plus longue ([RFC 6781, section 3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
Le calendrier de rotation de la ZSK dépend des TTL des RRsets DNSKEY et des signatures, de la propagation de la zone et de la durée pendant laquelle les signatures produites avec une clé en cours de retrait peuvent rester dans les caches des résolveurs ([RFC 7583, section 3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)). Pour une ZSK en ligne dont l'exposition à un risque de compromission est relativement élevée, la [RFC 6781, section 3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) décrit une durée de vie visée d'un mois comme raisonnable ; il s'agit d'une recommandation conditionnelle, et non d'un intervalle de rotation universel.
Rotation de la KSK de la zone racine le 11 octobre 2026
ICANN indique que la rotation de la KSK de la zone racine est prévue le 11 octobre 2026. Vérifiez que votre résolveur validant a chargé KSK-2024 (identifiant de clé 38696) comme ancre de confiance ; ne supposez pas que les mécanismes de mise à jour automatique ont fonctionné. Si la clé est absente, vérifiez que les mises à jour automatiques sont activées et suivez les instructions de l'éditeur de votre résolveur. Consultez les [recommandations d'ICANN sur la rotation de la KSK racine](https://www.icann.org/resources/pages/ksk-rollover-en) pour connaître les informations à jour.
Processus de validation DNSSEC
1. Le client demande au résolveur DNS l'enregistrement A de example.com
2. Le résolveur récupère l'enregistrement A et sa signature RRSIG
3. Le résolveur récupère le RRset DNSKEY pour vérifier la signature RRSIG
4. Le résolveur valide l'enregistrement DS par rapport au RRset DNSKEY
5. La validation remonte la chaîne de confiance jusqu'à la zone racine et vérifie chaque niveau
6. Si toutes les signatures sont valides, la réponse est authentifiée
Ce que la validation DNSSEC peut aider à détecter
Ces contrôles nécessitent des RRsets signés et un résolveur validant disposant d'une chaîne de confiance intacte. Les données non signées ou non sécurisées ne peuvent pas être authentifiées.
| Menace | Exemple | Protection de DNSSEC |
|---|---|---|
| Empoisonnement du cache | Données DNS falsifiées insérées dans le cache d'un résolveur | Un résolveur validant peut rejeter les données qui échouent à la validation de la signature ou de la chaîne. |
| Altération d'une réponse | Modification en transit d'un ensemble d'enregistrements DNS signé | Les données modifiées échouent à la vérification de signature. |
| Usurpation DNS | Réponse falsifiée fournie pour une zone signée | Un résolveur validant peut rejeter une réponse qui échoue à la validation. |
Considérations relatives à la mise en œuvre
- Performance: réponses plus importantes en raison des signatures (~1000-4000 octets vs ~100 octets)
- Gestion des clés: Nécessite une génération, un stockage et une rotation de clés sécurisées
- Signature de zone: Doit resigner la zone lorsque les enregistrements changent
- Prise en charge de DNSSEC par les résolveurs : les clients ont besoin de résolveurs qui valident DNSSEC
Meilleures pratiques
1. Choisir un algorithme de signature DNSSEC : le [registre des algorithmes DNSSEC de l'IANA](https://www.iana.org/assignments/dns-sec-alg-numbers) recommande ECDSAP256SHA256 (algorithme 13) pour la signature et la validation. ECDSAP384SHA384 (14) peut convenir aux besoins d'un niveau de sécurité de 192 bits ; vérifiez la prise en charge par les résolveurs avant de changer d'algorithme ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624, section 3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automatiser la rotation des clés : utilisez des outils comme OpenDNSSEC pour gérer le cycle de vie des clés
3. Surveiller l'expiration des signatures : les signatures RRSIG ont une période de validité
4. Tester avant le déploiement : validez la zone avec des outils comme dnsviz.net
5. Prévoir les situations d'urgence : documentez les procédures de rotation des clés
Lorsqu'un résolveur validant vérifie la chaîne, DNSSEC authentifie l'origine et l'intégrité des données DNS signées. Cela ne permet pas d'établir qu'un site web ou un serveur à l'adresse renvoyée est digne de confiance.