Hier, une opération fondamentale pour la sécurité du web s’est déroulée presque de manière invisible : la racine du DNS a commencé à utiliser la nouvelle clé KSK-2024 pour signer ses enregistrements DNSSEC. Il ne s’agit pas de remplacer le DNS ou de modifier les adresses des sites, mais de renouveler l’ancre cryptographique qui permet aux résolveurs de vérifier que les réponses reçues n’ont pas été falsifiées. Ce changement n’est que le deuxième de ce type depuis la mise en œuvre de DNSSEC au niveau de la racine.
Une clé au sommet de la chaîne de confiance
Lorsqu’un utilisateur saisit une adresse, un résolveur DNS recherche l’adresse IP correspondante. DNSSEC ajoute des signatures numériques à ce mécanisme. Ainsi, un résolveur conforme peut vérifier qu’une réponse est authentique et qu’un attaquant ne l’a pas remplacée au cours du processus. La validation se fait depuis la zone demandée jusqu’à son extension, puis vers la racine. À ce stade, il n’existe plus de niveau supérieur capable d’attester de l’identité de la clé : par conséquent, le résolveur doit déjà disposer d’une ancre de confiance.
Cette ancre est la KSK ou clé de signature de clé. Elle signe toutes les clés dans la zone racine, tandis qu’une autre clé, la ZSK, signe les données actuelles. La KSK-2024, identifiée par le numéro 38696, succède à la KSK-2017, identifiée par le numéro 20326. Les deux continuent d’utiliser RSA/SHA-256 : le changement concerne la paire de clés, et non l’algorithme cryptographique.
Cette distinction est importante car un échec de validation ne ressemble pas à une panne de serveur. Un site peut fonctionner normalement tout en étant inaccessible aux utilisateurs d’un résolveur qui rejette sa chaîne DNSSEC. Les récentes tensions autour de Quad9 DNS en France nous rappellent que les résolveurs constituent une couche essentielle, souvent négligée, de l’accès à Internet.
Pourquoi la majorité des internautes n’ont rien eu à faire
Ce changement a été préparé bien à l’avance. La KSK-2024 a été publiée dans l’ensemble DNSKEY racine depuis le 11 janvier 2025. De ce fait, les logiciels prenant en charge le mécanisme RFC 5011 ont pu observer la nouvelle clé, la vérifier grâce à l’ancienne clé, puis l’adopter automatiquement après une période d’attente minimale de trente jours. Les versions récentes de nombreux résolveurs incluaient également directement la nouvelle ancre.
Pour un utilisateur utilisant le DNS de son opérateur, son navigateur ou un service public comme 1.1.1.1, aucune intervention n’était généralement nécessaire. Le risque concernait principalement les infrastructures qui validaient DNSSEC avec des logiciels obsolètes, une configuration fixe ou un état de pin perdu lors d’une migration. Dans ce cas, le résolveur pouvait renvoyer une erreur SERVFAIL pour des domaines qui sont pourtant valides.
Cloudflare a publié un test basé sur le RFC 8509. Le principe consiste à poser deux questions spécifiques au résolveur : l’une demandant s’il fait confiance à la KSK-2024, l’autre si ce n’est pas le cas. Un résultat de SERVFAIL n’est pas nécessairement mauvais, car le résolveur doit spécifiquement rejeter l’une des deux requêtes. Le test ajoute des vérifications pour distinguer une validation réussie d’un service qui ne comprend pas ce mécanisme.
Cette prudence découle de l’expérience de 2018. Lorsque la clé racine a été renouvelée pour la première fois, certains résolveurs avaient perdu l’ancre nouvellement apprise après une mise à jour ou un changement de machine. L’incident n’a pas provoqué une coupure d’Internet à l’échelle mondiale, mais il a montré qu’une opération cryptographique correcte pouvait encore échouer au niveau de l’exploitation.
Un exercice à grande échelle avant des changements plus ambitieux
Le renouvellement d’une clé limite sa durée d’utilisation et oblige l’écosystème à tester l’ensemble de la chaîne de distribution : publication, apprentissage, préservation, puis retrait. C’est également un moyen de maintenir des procédures qui seront essentielles si la racine adopte un jour un autre algorithme. L’ICANN a mentionné une transition future vers ECDSA P-256, dont les signatures sont plus compactes que RSA, mais ce développement est distinct du changement effectué en octobre.
Par conséquent, cette opération n’est pas une réponse directe au calcul quantique. Cloudflare expérimente déjà la validation de signatures ML-DSA-44, conçues pour résister aux attaques quantiques, mais sécuriser l’ensemble de DNSSEC de cette manière nécessiterait une adoption coordonnée par la racine, les extensions, les domaines et les résolveurs. Le renouvellement actuel vérifie principalement que l’écosystème sait comment modifier son point de départ sans provoquer une cascade d’erreurs.
Les pannes sur de grandes plateformes montrent comment des couches invisibles peuvent avoir un impact massif : une panne de Cloudflare ou un incident chez Amazon Web Services suffit à rendre de nombreux services inaccessibles. La différence ici est que l’opération a été planifiée, progressive et surveillée pendant plusieurs années.
Le calendrier ne s’arrête pas là : l’ancienne KSK-2017 doit être révoquée le 11 janvier 2027.
