Le 11 octobre 2026, l'IANA prévoit de renouveler la clé qui signe la zone racine du DNS. Cette opération, appelée rollover de la clé racine, n'est pas juste une mise à jour technique : la racine n'a pas de parent DNS capable d'authentifier la nouvelle clé. Concrètement, chaque résolveur validant devra apprendre à faire confiance à KSK-2024 avant qu'elle ne commence à signer les données de la zone.
Avant l'opération, les publications disponibles donnent deux lectures assez différentes. En juillet, environ 90 % des résolveurs ayant émis un signal lié à la RFC 8145 semblaient déjà avoir intégré la nouvelle clé. À l'inverse, une mesure basée sur la RFC 8509 estime qu'environ 70 % des tests compatibles signalaient KSK-2024 comme ancre de confiance. Le plus important : ces chiffres ne regardent pas exactement le même ensemble, ni le même type de comportement. On ne peut donc pas en tirer directement une estimation du nombre d'internautes susceptibles de rencontrer un problème.
Voici comment se déroule le renouvellement, ce que mesurent réellement ces signaux, et comment un opérateur peut vérifier sa propre infrastructure sans confondre un indicateur partiel avec un diagnostic complet.
Pourquoi le renouvellement de la clé racine est particulier
DNSSEC ajoute des signatures cryptographiques aux données du DNS. Un résolveur validant vérifie ces signatures avant de renvoyer une réponse à l'utilisateur. Si la validation passe, cela permet d'établir que les données proviennent bien de la zone attendue et qu'elles n'ont pas été altérées en cours de route.
Dans la plupart des cas, une clé peut être authentifiée par une clé située plus haut dans la hiérarchie. La clé de signature de zone, ou ZSK, est validée par la clé de signature de clé, ou KSK, au même niveau. Pour une clé de délégation, la zone parente publie un enregistrement DS : il permet de vérifier la clé de la zone fille.
La racine fait exception : elle n'a pas de parent. Il n'existe donc pas de clé « supérieure » capable de certifier la nouvelle clé directement. Le mécanisme prévu consiste à faire signer la nouvelle KSK par l'ancienne. Cette idée, résumée souvent par « l'ancienne signe la nouvelle », laisse aux résolveurs le temps d'observer la clé entrante et de l'ajouter à leurs ancres de confiance.
Le rôle de la période d'attente RFC 5011
La procédure d'actualisation automatique des ancres de confiance est décrite dans la RFC 5011. Elle prévoit une période de maintien (hold-down) d'au moins 30 jours, ou plus si le TTL initial concerné l'impose. Pendant ce laps de temps, le résolveur doit observer plusieurs ensembles DNSKEY validés incluant la nouvelle clé, avant de l'accepter.
L'objectif est simple : éviter qu'une observation ponctuelle (ou une réponse injectée) suffise à modifier une ancre de confiance. Si la procédure est respectée et si l'implémentation suit bien, un résolveur compatible pourra apprendre la nouvelle clé sans intervention manuelle.
Mais tout dépend de la configuration réelle. Un résolveur ancien, une mise à jour désactivée, une ancre configurée manuellement, ou une implémentation qui ne suit pas correctement la RFC peuvent bloquer l'automatisation. Et « la clé a été publiée » ne veut pas automatiquement dire « tous les résolveurs lui font confiance ».
Ce qui change en octobre 2026
Le renouvellement prévu ne consiste pas à changer d'algorithme cryptographique. On remplace une paire de clés publique/privée. La nouvelle clé, KSK-2024, a été publiée par l'IANA en juillet 2024, puis ajoutée au jeu DNSKEY de la racine en janvier 2025. Le calendrier indique une utilisation pour signer le jeu DNSKEY à partir du 11 octobre 2026.
Dans les mesures, les identifiants de clé servent à distinguer les deux KSK : 20326 correspond à KSK-2017 (l'ancienne clé) et 38696 à KSK-2024. Le point clé n'est pas seulement « la clé apparaît dans les réponses DNS », mais plutôt « les résolveurs validants l'ont-ils réellement intégrée à leurs ancres de confiance locales ».
Pour les utilisateurs, le scénario problématique reste assez ciblé. Si un résolveur valide DNSSEC ne reconnaît pas la clé nécessaire au moment où elle devient requise, il peut rejeter les réponses concernées et renvoyer une erreur, souvent visible comme un échec de résolution. Ce n'est pas une panne générale du DNS : l'impact dépend des résolveurs effectivement utilisés, de leur configuration, et de ce que chacun tente de joindre au moment du basculement.
Comment les mesures évaluent l'adoption de KSK-2024
On ne peut pas inspecter directement la configuration interne de chaque résolveur dans le monde. Les mesures passent donc par des signaux techniques émis par les résolveurs, ou par des requêtes de test permettant d'inférer leur comportement. Deux mécanismes reviennent dans les résultats : RFC 8145 et RFC 8509.
RFC 8145 : les résolveurs annoncent leurs ancres de confiance
La RFC 8145 décrit un signal envoyé par certains résolveurs vers les serveurs faisant autorité de la racine. Ce signal contient les identifiants des clés que le résolveur considère comme fiables. L'information peut être encodée dans un nom de requête ou transmise via une option EDNS.
Les opérateurs des serveurs racine peuvent alors compter les signaux reçus : ils estiment combien de résolveurs annoncent l'ancienne clé, la nouvelle, ou les deux. Dans l'analyse de Verisign portant sur les signaux observés en juillet 2026, environ 90 % des résolveurs déclarants avaient ajouté KSK-2024 à leurs ancres de confiance.
Ce signal est utile, mais il n'englobe pas tout : il ne couvre que les résolveurs qui choisissent d'émettre le mécanisme. Et surtout, « un résolveur » ne veut pas dire « un utilisateur ». Un résolveur d'entreprise utilisé par des millions de personnes compte pareil qu'un résolveur personnel n'en desservant qu'un seul. Autrement dit : le nombre d'émetteurs n'est pas un substitut parfait au nombre d'utilisateurs concernés.
RFC 8509 : tester la confiance depuis le point de requête
La RFC 8509 propose un autre mécanisme, appelé Root Key Trust Anchor Sentinel. Ici, le résolveur n'envoie pas l'information vers les serveurs racine : il modifie plutôt sa réponse à une requête spéciale. Le comportement attendu dépend de sa confiance (ou non) dans l'identifiant de clé demandé.
Dans les tests décrits par APNIC, les deux premières requêtes servent à vérifier que le résolveur prend en charge le mécanisme, et reconnaît l'ancienne clé (20326). Une troisième requête teste ensuite la présence de KSK-2024 (38696). Les réponses permettent alors de classer un échantillon comme compatible et d'estimer si la nouvelle clé est déjà connue comme ancre de confiance.
Ce type de test se rapproche davantage du point de vue utilisateur que le comptage des annonces RFC 8145 : APNIC envoie des requêtes depuis des dispositifs de mesure qui reflètent des systèmes utilisateurs. En revanche, ce n'est pas un recensement exhaustif et le test ne permet pas d'identifier chaque résolveur individuellement.
Un autre essai, mené avec des sondes RIPE Atlas le 5 octobre et couvrant 2 900 systèmes autonomes (AS), a trouvé 1 230 sondes avec un comportement compatible avec le mécanisme et une nouvelle clé chargée. Quarante-sept sondes avaient un comportement compatible avec un résolveur qui n'avait pas chargé la nouvelle clé. Là encore : on décrit les sondes testées, pas l'ensemble des utilisateurs des réseaux concernés.
Ce que les chiffres permettent - et ne permettent pas - de conclure
Les mesures d'APNIC basées sur des tests de requêtes ont été réalisées entre mai et juillet 2026, puis reprises au début d'octobre, avec environ 16 millions de tests par jour. Le volume impressionne, mais le dénominateur utile est plus petit. Environ 6 millions de tests quotidiens indiquaient que le système testé se trouvait derrière un résolveur validant DNSSEC. Environ 1,8 million fournissaient un signal clair de prise en charge du mécanisme RFC 8509.
Parmi ces tests compatibles, environ 70 % signalaient KSK-2024 comme clé de confiance. Ce résultat n'est pas forcément contradictoire avec les ~90 % observés via RFC 8145 : les méthodes, les périodes, les populations et les dénominateurs ne sont pas les mêmes. L'un compte des résolveurs qui émettent un signal vers les serveurs racine ; l'autre observe des réponses à des requêtes envoyées depuis des systèmes utilisateurs et ne garde qu'un sous-ensemble d'observations.
C'est pour ça que l'interprétation doit rester prudente. Un taux de 70 % sur des échantillons compatibles ne veut pas dire que 30 % des internautes seront touchés. Et ça ne signifie pas non plus que 70 % des résolveurs mondiaux sont prêts. Les chiffres décrivent un comportement mesuré sur des sous-groupes : ils ne donnent pas directement le nombre d'équipements qui échoueront après le changement.
Les réseaux les moins bien placés méritent une vérification, pas un verdict
Le tableau publié par APNIC liste les réseaux où le taux d'acceptation de KSK-2024 semblait plus faible, en ne retenant que ceux qui avaient au moins 1 000 tests indiquant une prise en charge de RFC 8509. On y voit des opérateurs de plusieurs régions, mais aussi des réseaux en Europe : Vodafone Libertel aux Pays-Bas, Vodafone en Tchéquie, ainsi que des réseaux au Luxembourg, en Suisse, en Islande et en Bulgarie.
Ces résultats sont utiles comme signal de vigilance, pas comme preuve que tous les abonnés de ces fournisseurs seront impactés. Les données restent des échantillons, peuvent regrouper plusieurs configurations de résolveurs, et n'indiquent pas forcément la part réelle de clients desservis par chaque configuration. Le tableau contient aussi plusieurs colonnes et dénominateurs : le bon réflexe est de ne pas transformer un taux observé en « classement final » de la qualité DNS d'un opérateur.
Pour un fournisseur d'accès, une entreprise ou un hébergeur, la bonne réaction n'est ni de paniquer ni d'ignorer. Il faut rapprocher les observations externes avec ce qui tourne chez soi : quels résolveurs sont réellement utilisés, quelles versions, comment les ancres sont gérées, et quels journaux montrent l'évolution ? C'est ce travail qui transforme un pourcentage en plan d'action.
Les deux approches ont donc des usages différents. RFC 8145 donne une vue agrégée des résolveurs qui annoncent leurs ancres. RFC 8509 teste le comportement depuis un point de mesure. Aucune des deux ne remplace un inventaire opérationnel des résolveurs, des tests contrôlés et une surveillance après le basculement.
Vérifications à mener avant et après le basculement
Pour un opérateur, un administrateur système ou une équipe réseau, le rollover doit être traité comme un changement planifié : critères de validation et plan de retour. Le point sensible, c'est de vérifier les composants qui font réellement la validation, pas seulement les serveurs DNS visibles dans la documentation.
Avant le changement : établir l'état réel
Commencez par l'inventaire des résolveurs récursifs utilisés par vos systèmes et par vos utilisateurs. En entreprise, les postes peuvent interroger un résolveur interne, un service DNS externalisé, le résolveur d'un VPN, ou un service public. Les appareils mobiles et les environnements domestiques peuvent suivre d'autres chemins.
Pour chaque résolveur validant, vérifiez :
- la version logicielle et la prise en charge de la mise à jour RFC 5011 ;
- l'origine de l'ancre de confiance : gestion automatique, configuration manuelle, ou paquet système ;
- la présence de KSK-2024 dans l'état local attendu, lorsque l'outil le permet ;
- les règles de filtrage, de transfert ou de cache susceptibles de modifier le comportement DNS ;
- les alertes et journaux liés aux erreurs de validation et aux réponses SERVFAIL.
Testez aussi plusieurs populations. Un test depuis le siège ne valide pas forcément ce que voient les agences, les clients VPN, ou les environnements hébergés. Dans les infrastructures complexes, explicitez les chemins DNS dans vos procédures de changement.
Pendant et après : regarder les bons symptômes
Avant la date de basculement, documentez une base de référence : taux d'échec de résolution, volumes de SERVFAIL, alertes DNSSEC, et comportement des contrôles synthétiques. Après le changement, comparez ces indicateurs à vos valeurs habituelles. Une hausse de SERVFAIL mérite une analyse, mais ne suffit pas à conclure à un problème lié à KSK : une zone mal signée, une horloge incorrecte, ou une panne réseau peuvent produire des symptômes similaires.
Si votre organisation exploite son propre résolveur, suivez les recommandations du fournisseur du logiciel DNS et de l'IANA. Si vous dépendez d'un fournisseur d'accès ou d'un prestataire DNS, transmettez-lui des informations concrètes : heure du test, réseau concerné, résolveur interrogé, nom testé et résultat. « Notre DNS ne marche pas » est rarement exploitable ; une erreur reproductible et bien documentée fait gagner un temps précieux.
Pour un particulier, il n'y a en général rien à faire manuellement côté clés DNS. Si des sites deviennent inaccessibles autour de l'opération, comparez le comportement via un autre réseau et contactez l'opérateur concerné. Changer immédiatement de résolveur peut contourner le symptôme, mais ça ne corrige pas la cause chez l'opérateur.
Les références utiles sont la page IANA sur la gestion de la clé racine, les RFC 5011, RFC 8145 et RFC 8509, ainsi que l'analyse d'APNIC. Elles aident à distinguer le calendrier, le mécanisme de confiance et les limites des observations disponibles.
Conclusion : traiter le rollover comme un exercice opérationnel
Le renouvellement de la clé racine repose sur un mécanisme éprouvé, mais la réussite dépend de la diversité des résolveurs déployés et de leur configuration réelle. Les signaux disponibles montrent une adoption importante de KSK-2024, tout en laissant apparaître des réseaux pour lesquels des vérifications supplémentaires sont raisonnables. Ils ne permettent pas, à eux seuls, de convertir un pourcentage en estimation du nombre d'utilisateurs réellement impactés.
Pour les équipes techniques, l'essentiel est assez concret : inventorier les résolveurs, confirmer la gestion des ancres, surveiller les erreurs de validation, et tester les chemins DNS réellement utilisés. Pour les autres, la meilleure approche est de s'appuyer sur des symptômes reproductibles et de contacter l'opérateur concerné plutôt que de modifier des paramètres DNS à l'aveugle.
Si vous exploitez un résolveur, ajoutez dès maintenant le contrôle de KSK-2024 à votre procédure de changement, et conservez des résultats avant/après le basculement. Ce n'est peut-être pas une vérification parfaite, mais c'est clairement plus utile que de compter sur une mise à jour automatique « pour tout le monde ».