DNSSEC : ce qui change le 11 octobre 2026, et qui est concerné

Le 11 octobre 2026, une petite modification technique aura lieu tout en haut du système DNS. Elle devrait passer totalement inaperçue pour la majorité des internautes. Mais pour certains administrateurs réseau, elle mérite une vérification avant le jour J.

La clé de signature de clé de la racine DNS, ou KSK, va être remplacée. C’est seulement le deuxième changement de ce type depuis la mise en place de DNSSEC à la racine.

Cloudflare a rappelé l’échéance le 6 octobre. L’ICANN et l’IANA préparent ce basculement depuis plusieurs années.

À quoi sert cette clé ?

Le DNS est le système qui permet de transformer un nom comme example.com en une adresse utilisable par les machines.

DNSSEC ajoute une couche de vérification cryptographique. Son rôle est de permettre à un résolveur DNS de vérifier que les informations reçues sont authentiques et n’ont pas été modifiées en chemin.

Cette vérification repose sur une chaîne de confiance. Pour un domaine en .com, elle part de la racine du DNS, passe par .com, puis arrive jusqu’au domaine recherché.

Il faut donc un point de départ auquel le résolveur fait déjà confiance. C’est le rôle de la KSK de la racine, utilisée comme ancre de confiance.

Ce qui change le 11 octobre

La clé actuellement utilisée, KSK-2017, porte le tag 20326. Elle sera remplacée pour la signature par KSK-2024, dont le tag est 38696.

La nouvelle clé n’arrive pas au dernier moment. Elle est publiée dans la zone racine depuis le 11 janvier 2025, afin de laisser aux résolveurs le temps de l’apprendre et de lui accorder leur confiance.

Les logiciels compatibles avec le mécanisme défini par la RFC 5011 peuvent effectuer cette mise à jour automatiquement. Ils doivent notamment observer la nouvelle clé pendant une période d’au moins 30 jours avant de l’accepter comme nouvelle ancre de confiance.

Le 11 octobre 2026, KSK-2024 deviendra la clé utilisée pour signer l’ensemble DNSKEY de la racine. Un résolveur qui valide DNSSEC devra donc déjà lui faire confiance.

Un détail important : l’algorithme cryptographique ne change pas. KSK-2017 et KSK-2024 utilisent toutes les deux RSA/SHA-256. Il s’agit d’un renouvellement de clé, pas d’une migration vers une nouvelle famille d’algorithmes.

Qui est réellement concerné ?

Le changement concerne surtout les organisations qui exploitent leurs propres résolveurs DNS récursifs avec validation DNSSEC : fournisseurs d’accès, hébergeurs, entreprises, administrations ou opérateurs réseau, par exemple.

Pour un internaute classique, il n’y a normalement rien à faire. Même chose pour la majorité des propriétaires de sites : héberger un domaine ou activer DNSSEC sur celui-ci ne signifie pas que l’on exploite soi-même le résolveur récursif utilisé par les visiteurs.

Cloudflare indique par exemple que ses services 1.1.1.1 et Gateway DNS font déjà confiance à KSK-2024.

L’ICANN se montre également rassurante sur l’état de préparation général. En juillet 2026, elle indiquait que plus de 95 % des résolveurs répertoriés dans ses données avaient reconnu et adopté KSK-2024.

Cela ne signifie pas que tous les résolveurs de la planète ont été vérifiés. Mais les données disponibles ne suggèrent pas un risque de panne généralisée.

Que se passe-t-il si un résolveur n’a pas la nouvelle clé ?

C’est là que le problème peut devenir trompeur.

Un site peut fonctionner normalement, son serveur peut être disponible et sa configuration DNS peut être correcte. Pourtant, les utilisateurs placés derrière un résolveur mal préparé peuvent ne plus réussir à résoudre les noms de domaine.

Le résolveur considère alors que la chaîne de confiance DNSSEC ne peut plus être validée. Les requêtes concernées peuvent se terminer par une erreur de type SERVFAIL, ce qui rend les sites et services inaccessibles pour les utilisateurs de ce résolveur.

À l’échelle d’Internet, le risque apparaît limité. À l’échelle d’une entreprise, d’un opérateur ou d’un réseau qui utiliserait un résolveur concerné, l’impact peut en revanche être important.

La vérification à faire avant le 11 octobre

L’ICANN recommande aux opérateurs de résolveurs DNSSEC de ne pas simplement supposer que la mise à jour automatique a fonctionné.

La vérification principale consiste à confirmer que KSK-2024, tag 38696, est bien présente dans la configuration des ancres de confiance.

L’ICANN cite notamment les fichiers suivants selon les logiciels :

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

Si la clé 38696 est absente, l’ICANN recommande de vérifier le mécanisme de mise à jour automatique puis de suivre les instructions du fournisseur du logiciel pour mettre les ancres de confiance à jour.

L’IANA publie également le jeu officiel des ancres de confiance de la racine DNS.

Un test simple, avec une limite

Cloudflare propose aussi un test de préparation au rollover. Il s’appuie sur le mécanisme Root Key Trust Anchor Sentinel défini par la RFC 8509 pour demander au résolveur utilisé s’il fait confiance à KSK-2024.

Ce test peut être pratique, mais son résultat doit être interprété correctement. Si le résolveur ne prend pas en charge ce mécanisme, le résultat peut être inconclusif. Cela ne signifie pas automatiquement que la nouvelle clé est absente.

Le test effectué dans un navigateur peut également refléter le DNS réellement utilisé par ce navigateur, y compris lorsqu’un VPN ou un mécanisme de DNS sécurisé modifie le chemin habituel des requêtes.

Faut-il s’attendre à une panne d’Internet ?

Les éléments disponibles ne vont pas dans ce sens.

Le changement est préparé depuis longtemps, la nouvelle clé est publiée depuis janvier 2025 et l’adoption mesurée par l’ICANN est déjà très élevée. Pour la majorité des utilisateurs, le 11 octobre ne devrait produire aucun changement visible.

L’intérêt du sujet est ailleurs : le DNS fait partie de ces infrastructures que l’on remarque surtout lorsqu’elles cessent de fonctionner. Un résolveur oublié, ancien ou mal configuré peut suffire à rendre une grande partie du Web inaccessible depuis un réseau donné, alors que les sites eux-mêmes n’ont aucun problème.

Pour les équipes qui administrent un résolveur DNSSEC, le contrôle est donc simple : vérifier la présence de la KSK-2024 et du tag 38696 avant le 11 octobre 2026.