DNS : la clé racine change le 11 octobre, qui doit vérifier quoi

Le 11 octobre 2026, la racine du DNS, l'annuaire qui traduit les noms de domaine en adresses, change de clé de signature principale. La nouvelle clé, KSK-2024 (identifiant 38696), remplacera KSK-2017 pour signer la zone racine, rappelle l'ICANN (ouvre icann.org dans un nouvel onglet)Aller vers icann.org. Un résolveur qui vérifie les signatures DNSSEC sans connaître la nouvelle clé ne pourra plus résoudre aucun nom. Pour la très grande majorité des internautes, en revanche, rien ne se passera.

Un calendrier lancé en 2024

La KSK est la clé « maîtresse » de DNSSEC, le mécanisme qui permet de vérifier qu'une réponse DNS n'a pas été falsifiée. Tout résolveur qui valide ces signatures doit la connaître : c'est son « ancre de confiance ». D'après l'IANA (ouvre iana.org dans un nouvel onglet)Aller vers iana.org et la présentation de l'ICANN à DNS-OARC (ouvre indico.dns-oarc.net dans un nouvel onglet)Aller vers indico.dns-oarc.net, le changement se déroule par étapes :

• 26 avril 2024 : génération de KSK-2024 ;
• 11 janvier 2025 : publication dans la zone racine, à côté de l'ancienne clé ;
• 10 février 2025 : après 30 jours d'observation, les résolveurs qui se mettent à jour automatiquement (procédure dite RFC 5011) peuvent lui faire confiance ;
• 11 octobre 2026 : KSK-2024 commence à signer, KSK-2017 s'arrête ;
• 11 janvier 2027 : KSK-2017 doit être révoquée, c'est-à-dire marquée comme invalide, avant son retrait.

C'est le deuxième changement depuis 2010 ; le premier, repoussé d'un an, a eu lieu le 11 octobre 2018. Selon l'ICANN (ouvre icann.org dans un nouvel onglet)Aller vers icann.org, plus de 95 % des résolveurs qui remontent des données reconnaissent déjà la nouvelle clé.

Qui risque une panne

Le risque ne concerne que les résolveurs qui valident DNSSEC et n'ont que KSK-2017 en ancre de confiance. Le guide de l'ICANN (ouvre icann.org dans un nouvel onglet)Aller vers icann.org explique que les échecs commenceront dans les 48 heures après la bascule, au moment où le résolveur rechargera les clés de la racine, sans qu'on puisse prédire l'instant exact. Symptômes : pages inaccessibles, courriels bloqués, puis plus rien. Les systèmes automatisés tombent aussi.

Sont surtout concernés les entreprises, hébergeurs et administrateurs qui font tourner leur propre résolveur (BIND, Unbound, Knot Resolver, PowerDNS Recursor). L'ICANN cite aussi les applications conteneurisées et les logiciels qui embarquent leur propre résolveur, par exemple en DNS-over-HTTPS : il faut alors savoir lequel ils utilisent.

Comment vérifier

L'ICANN demande de ne pas supposer que la mise à jour automatique a fonctionné et de chercher l'identifiant 38696 dans le fichier d'ancre de confiance :

• BIND : bind.keys ;
• Unbound et PowerDNS Recursor : root.key ;
• Knot Resolver : root.keys.

S'il manque, il faut vérifier que la mise à jour automatique est active et que le résolveur peut écrire dans son dossier de stockage. Selon la présentation de l'ICANN, la clé est intégrée à partir d'Unbound 1.21.0, Knot Resolver 5.7.4 et 6.0.8, BIND 9.18.33 et 9.20.4, et PowerDNS Recursor 5.2.0. En cas de panne, l'ICANN évoque une solution d'urgence : couper temporairement la validation, puis installer KSK-2024 et la réactiver.

Crédit : IANA (ouvre iana.org dans un nouvel onglet)Aller vers iana.org, capture de la page officielle des ancres de confiance, 7 octobre 2026.

Et le grand public ?

Rien à faire sur un PC ou un smartphone : il n'y a aucun réglage à changer. La mise à jour revient à l'opérateur du résolveur utilisé (fournisseur d'accès, entreprise ou service DNS public). Si, après le 11 octobre, des sites deviennent inaccessibles alors que la connexion fonctionne, le résolveur peut être en cause : l'ICANN note qu'un système doté de plusieurs résolveurs basculera vers celui qui est prêt.

Notre lecture (Analyse.) En 2018, le changement s'était passé sans incident majeur, et les chiffres de l'ICANN vont dans le même sens. Le vrai risque se trouve dans les machines oubliées : boîtiers réseau jamais mis à jour, images de conteneurs figées, serveurs de test. Pour les administrateurs, une vérification de cinq minutes avant dimanche vaut mieux qu'un incident lundi matin. Même réflexe que pour les mises à jour d'OpenSSH ou le reste de notre rubrique cybersécurité.