Accueil / Nommage
DNSSEC et la cérémonie de la clé
DNSSEC ne chiffre rien. Il signe. Chaque niveau du DNS certifie la clé du niveau inférieur, si bien qu'un résolveur qui connaît une seule clé — celle de la racine — peut vérifier n'importe quelle réponse. Cette clé unique est fabriquée au cours d'une cérémonie filmée, et elle change dans — jours.
Signer, et non chiffrer
Le DNS d'origine n'a aucun moyen de prouver qu'une réponse vient bien du serveur légitime. Un attaquant capable d'insérer une réponse plus rapide que la vraie fait accepter n'importe quelle adresse. C'est le défaut structurel que DNSSEC corrige — et le seul.
Ce que DNSSEC garantit
- Authenticité de l'origine. La réponse vient bien du détenteur de la zone.
- Intégrité. Elle n'a pas été modifiée en chemin.
- Preuve d'inexistence. Point souvent oublié : DNSSEC prouve aussi qu'un nom n'existe pas, ce qui empêche d'inventer des sous-domaines.
Ce que DNSSEC ne garantit pas
- La confidentialité. Les requêtes et réponses restent en clair. C'est le rôle de DoT, DoH ou DoQ.
- La disponibilité. Au contraire : une signature expirée transforme une donnée correcte en panne franche.
- L'honnêteté du titulaire. Un domaine malveillant peut être parfaitement signé. DNSSEC prouve l'origine, pas les intentions.
DNSSEC échoue de façon bruyante, par conception
Quand une signature ne valide pas, le résolveur ne sert pas la donnée douteuse : il renvoie une erreur. C'est un choix délibéré — mieux vaut aucune réponse qu'une mauvaise adresse — mais cela signifie qu'une erreur d'exploitation devient immédiatement une indisponibilité visible.
C'est ce qui s'est produit en Allemagne au deuxième trimestre 2026, quand des signatures erronées ont été diffusées : les domaines concernés sont devenus injoignables pour tous les utilisateurs derrière un résolveur qui valide correctement, et parfaitement accessibles pour les autres. Ce type de panne asymétrique est difficile à diagnostiquer depuis le support client.
Signature, pas chiffrement
Analogie : DNSSEC est un cachet de cire sur une lettre envoyée à découvert. N'importe qui peut lire la lettre, mais le cachet brisé se voit. Le chiffrement du transport, lui, est l'enveloppe opaque — et il ne dit rien de l'authenticité du contenu.
Les six briques de DNSSEC
| Type | Nom complet | Rôle |
|---|---|---|
| DNSKEY | Clé publique de zone | Publie les clés publiques de la zone. Deux usages : KSK (indicateur 257) et ZSK (indicateur 256). |
| RRSIG | Signature d'un ensemble | La signature cryptographique d'un groupe d'enregistrements, avec sa date de début et de fin de validité. |
| DS | Signataire de délégation | Publié dans la zone parente. Contient l'empreinte de la KSK de l'enfant. C'est le maillon qui relie deux niveaux. |
| NSEC | Prochain nom sécurisé | Prouve qu'un nom n'existe pas, en indiquant les noms voisins. Effet de bord : permet d'énumérer la zone. |
| NSEC3 | Variante hachée | Même fonction, avec des empreintes au lieu des noms, pour limiter l'énumération. |
| CDS / CDNSKEY | DS et clé « enfant » | Permettent à un domaine de signaler à son parent qu'il faut mettre à jour son DS, sans intervention manuelle. Clé de l'automatisation des rotations. |
Pourquoi deux clés au lieu d'une
La séparation entre KSK et ZSK est un compromis d'exploitation. La KSK ne signe qu'une chose : l'ensemble des clés de la zone. Elle change rarement, et son empreinte doit être publiée chez le parent — opération lente et coordonnée. La ZSK signe tous les autres enregistrements ; elle est plus exposée et se renouvelle souvent, sans jamais impliquer le parent.
À la racine, la ZSK est renouvelée chaque trimestre. La KSK, elle, n'a changé qu'une fois depuis 2010 — et change une seconde fois le 11 octobre 2026.
Algorithmes en usage
La racine utilise l'algorithme 8, soit RSA avec SHA-256. L'algorithme 13, ECDSA sur la courbe P-256, produit des signatures beaucoup plus courtes et gagne du terrain dans les zones ordinaires. Le passage de la racine à ECDSA fait l'objet d'une consultation publique ouverte par l'ICANN en février 2026 : génération d'une nouvelle clé en 2027, retrait de la clé RSA en 2029.
La chaîne de confiance, maillon par maillon
Sélectionnez un maillon pour comprendre ce qui le protège, puis coupez-le pour voir la cascade d'échecs. Les flèches haut et bas fonctionnent au clavier.
Le rituel le plus filmé de l'informatique mondiale
La clé privée qui signe la racine du DNS n'existe nulle part en clair. Elle vit à l'intérieur de modules matériels de sécurité conservés dans deux installations distantes, l'une sur la côte ouest des États-Unis, l'autre sur la côte est, afin qu'aucun sinistre local ne puisse détruire les deux.
Quatre fois par an environ, l'IANA réunit une cérémonie pour utiliser cette clé. Elle sert à signer les clés de zone du trimestre suivant. Rien d'autre. L'opération dure quelques heures et suit un script écrit à l'avance, ligne par ligne, lu à voix haute.
La répartition du contrôle
Le contrôle n'est pas confié à une organisation mais réparti entre des représentants de la communauté de confiance, bénévoles venus de plusieurs pays et sélectionnés publiquement. Deux rôles distincts :
- Les officiers de cryptographie détiennent chacun une carte à puce, conservée dans un coffre individuel à l'intérieur de l'installation. Plusieurs cartes sont nécessaires pour activer les modules.
- Les détenteurs de parts de recouvrement conservent des fragments permettant de reconstruire le système en cas de destruction complète.
Personne ne peut agir seul, et aucune organisation ne détient assez d'éléments pour contourner les autres.
La vérifiabilité comme sécurité
Tout est filmé et diffusé publiquement. Les scripts, les journaux d'audit et les photographies sont publiés après chaque cérémonie. Un auditeur externe certifie les contrôles par un rapport indépendant. La sécurité ne repose pas sur le secret des procédures, mais sur le fait que n'importe qui peut les vérifier après coup.
Le déroulement type
Entrée dans une salle sans fenêtre, sous caméras. Vérification d'identité de chaque participant. Ouverture du coffre à équipement, puis du coffre à identifiants. Retrait des modules de leurs sacs inviolables, dont les numéros de série sont lus à haute voix et consignés. Activation par les cartes à puce. Exécution de la signature. Impression et vérification du résultat. Remise sous scellés, avec de nouveaux numéros de série consignés. Signature du procès-verbal par tous les présents.
Pourquoi tant de théâtre
Chaque geste répond à une menace précise. Les sacs inviolables détectent une manipulation entre deux cérémonies. La lecture à voix haute des numéros de série crée une trace vidéo horodatée. La présence de témoins indépendants empêche qu'une contrainte exercée sur une personne suffise. La diffusion publique fait que toute anomalie serait relevée par des observateurs extérieurs à l'organisation.
Un modèle qui a fait école
Le même schéma — matériel scellé, contrôle réparti, script public, audit indépendant, diffusion vidéo — a depuis été repris par plusieurs registres nationaux et par des infrastructures à clés publiques d'entreprise. La cérémonie de la racine est le cas d'école le mieux documenté au monde.
Seize ans, deux bascules
Juillet 2010 — signature de la racine
Première publication d'une zone racine signée, après une décennie de travaux. KSK-2010 devient l'ancre de confiance mondiale.
11 octobre 2018 — première bascule
KSK-2017 remplace KSK-2010, après un report d'un an décidé en septembre 2017 devant l'incertitude sur la préparation des résolveurs. L'opération se passe sans incident majeur.
Avril 2024 — génération
KSK-2024 est produite lors d'une cérémonie dans la première installation, puis répliquée dans la seconde. La clé privée ne quitte jamais les modules matériels.
2024 → 2026 — pré-publication
La nouvelle clé publique est publiée dans la racine sans rien signer, pendant près de deux ans. Les résolveurs l'apprennent automatiquement par le mécanisme du RFC 5011.
Mars 2025 — mesure
Verisign estime, à partir des signaux d'ancre de confiance décrits par le RFC 8145, que 91,3 % des résolveurs observés ont déjà enregistré KSK-2024 — un rythme comparable à celui de 2018.
11 octobre 2026 — bascule
KSK-2024 devient la seule clé qui signe la racine. Les résolveurs restés sur l'ancienne ancre échouent à valider et renvoient des erreurs à leurs utilisateurs.
Janvier 2027 — révocation
KSK-2017 est formellement révoquée. Elle reste publiée avec un indicateur de révocation, pour que les résolveurs sachent qu'il ne s'agit pas d'une disparition accidentelle.
Mi-2027 — destruction
La clé est effacée des deux installations de gestion. Le cycle recommence : l'IANA vise désormais un rythme de rotation d'environ trois ans.
Qui va casser
Trois populations, dans l'ordre de risque décroissant :
1. Les ancres codées en dur. Configurations écrites à la main en 2010 ou 2018, images de conteneurs figées, équipements embarqués jamais mis à jour. Le RFC 5011 ne les concerne pas : personne n'a activé sa mise à jour automatique.
2. Les résolveurs jamais redémarrés. Le mécanisme du RFC 5011 exige que le processus tourne et observe la racine pendant la période de pré-publication. Un système restauré à partir d'une sauvegarde ancienne peut avoir manqué la fenêtre.
3. Les relais mal configurés. Certaines box et pare-feu ne transmettent pas correctement les enregistrements DNSSEC, ce qui produit des échecs indépendants de la clé elle-même.
Comment vérifier, aujourd'hui
Sur un résolveur BIND, la commande rndc managed-keys status liste les ancres connues et leur état. Sur Unbound, unbound-anchor -l affiche le fichier d'ancre courant. Une ancre à jour contient deux clés, dont celle dont l'identifiant correspond à KSK-2024 publié par l'IANA.
Un test fonctionnel simple : interroger un domaine délibérément mal signé. Si votre résolveur le résout, il ne valide pas. S'il renvoie SERVFAIL, il valide.
Ce que verra un utilisateur
Pas un message d'erreur explicite. Une page qui ne charge pas, une application qui tourne dans le vide, un courriel qui n'arrive pas. Rien n'indiquera qu'il s'agit d'un problème de clé. C'est pourquoi la préparation doit se faire côté opérateur, avant la date.
Où en est réellement le déploiement
Signer une zone ne sert que si quelqu'un vérifie la signature. Les deux moitiés du problème progressent à des vitesses très différentes.
Part des utilisateurs derrière un résolveur qui valide. Rapport du Centre commun de recherche de la Commission, 3ᵉ trimestre 2025.
Même source. Les mesures d'APNIC Labs donnent un ordre de grandeur voisin, autour de 35 à 38 % selon la période.
Estimation 2025. Le taux varie énormément d'une extension à l'autre : très élevé dans certains pays nordiques, marginal ailleurs.
Mesure Cloudflare Radar, mi-2026, en croissance rapide mais depuis un niveau très bas.
Le débat, honnêtement
DNSSEC a des détracteurs sérieux. Geoff Huston, scientifique en chef d'APNIC, a publiquement questionné son utilité pratique : quinze ans après la signature de la racine, la validation de bout en bout reste marginale, la complexité opérationnelle est réelle, et les pannes causées par des erreurs de signature sont plus fréquentes que les attaques évitées.
Les arguments en face sont également solides :
- Un tiers des utilisateurs mondiaux sont derrière un résolveur qui valide. Ce n'est pas marginal.
- DNSSEC est le seul mécanisme qui protège contre un résolveur trompé en amont, ce que le chiffrement du transport ne fait pas.
- Il est le préalable de DANE, qui permet de publier ses propres empreintes de certificats dans le DNS.
- Depuis le 15 mars 2026, les autorités de certification doivent tenir compte de DNSSEC lors de la validation d'un domaine — bulletin SC-085v2 du CA/Browser Forum. Une zone signée protège désormais aussi l'émission de vos certificats.
Position raisonnable
Pour un site vitrine sans données sensibles, signer apporte peu. Pour un domaine qui porte de l'authentification, du courrier, des paiements ou une marque, le rapport a changé avec l'entrée en vigueur de SC-085v2 : la signature protège désormais un maillon supplémentaire.
Quand ça casse
Le symptôme unique
Presque tous les problèmes DNSSEC se manifestent de la même façon : SERVFAIL. C'est peu informatif, et volontairement : le résolveur ne dit pas ce qui a échoué, il dit qu'il n'a pas pu prouver la réponse.
Le premier réflexe consiste à distinguer un problème de validation d'un problème de données :
Les cinq causes les plus fréquentes
- Signature expirée. Les RRSIG ont une date de fin. Une signature automatique qui s'arrête produit une panne quelques jours plus tard, sans alerte préalable.
- DS obsolète. La clé du domaine a changé mais l'empreinte publiée chez le registre pointe encore vers l'ancienne. Cause classique d'un changement d'hébergeur DNS mal séquencé.
- Rotation trop rapide. La nouvelle clé est en place avant que les caches aient oublié l'ancienne. D'où la règle du TTL abaissé plusieurs jours à l'avance.
- Relais qui tronque. Un équipement intermédiaire ne transmet pas les réponses volumineuses ou supprime les enregistrements DNSSEC.
- Zone signée à moitié. DNSKEY publié mais DS jamais transmis au registre : le domaine n'est en réalité pas protégé. Cette configuration incomplète est très répandue.
Outils de diagnostic
DNSViz produit un graphe complet de la chaîne de confiance d'un domaine et indique exactement quel maillon échoue. Zonemaster, développé par des registres européens, effectue un contrôle global d'une délégation. Le vérificateur DNSSEC de Verisign donne une lecture pas à pas. Tous trois sont publics et gratuits.