Une opération presque invisible, mais décisive pour la sécurité du Web, a eu lieu hier : 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 ni 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. C’est seulement la deuxième bascule de ce type depuis le déploiement de DNSSEC à la racine.
Une clé qui se trouve au sommet de la chaîne de confiance
Lorsqu’un internaute saisit une adresse, un résolveur DNS cherche l’adresse IP correspondante. DNSSEC ajoute des signatures numériques à ce mécanisme. Un résolveur compatible peut ainsi vérifier qu’une réponse est authentique et qu’un attaquant ne l’a pas remplacée en chemin. La validation remonte de la zone demandée vers son extension, puis jusqu’à la racine. À cet endroit, il n’existe plus de niveau supérieur capable d’attester l’identité de la clé : le résolveur doit donc déjà posséder une ancre de confiance.
Cette ancre est la KSK, ou Key Signing Key. Elle signe l’ensemble des clés de la zone racine, tandis qu’une autre clé, la ZSK, signe les données courantes. KSK-2024, identifiée par le numéro 38696, succède à KSK-2017, identifiée par le numéro 20326. Les deux utilisent encore RSA/SHA-256 : le changement porte sur la paire de clés, pas sur l’algorithme cryptographique.
La distinction importe, car une panne de validation ne ressemble pas à une panne de serveur. Un site peut fonctionner normalement tout en devenant inaccessible pour les utilisateurs d’un résolveur qui refuse sa chaîne DNSSEC. Les récentes tensions autour du DNS Quad9 en France ont rappelé que les résolveurs constituent une couche centrale, souvent méconnue, de l’accès à Internet.
Pourquoi la majorité des internautes n’a rien eu à faire
La bascule a été préparée longtemps à l’avance. KSK-2024 était publiée dans l’ensemble DNSKEY de la racine depuis le 11 janvier 2025. Les logiciels conformes au mécanisme RFC 5011 ont donc pu observer la nouvelle clé, la vérifier à l’aide de l’ancienne puis l’adopter automatiquement après un délai d’attente minimal de trente jours. Les versions récentes de nombreux résolveurs embarquaient aussi directement la nouvelle ancre.
Pour un particulier qui utilise le DNS de son opérateur, de son navigateur ou un service public comme 1.1.1.1, aucune intervention n’était normalement nécessaire. Le risque concernait surtout des infrastructures qui valident elles-mêmes DNSSEC avec un logiciel ancien, une configuration figée ou un état d’ancre perdu lors d’une migration. Dans ce cas, le résolveur peut retourner une erreur SERVFAIL pour des domaines pourtant valides.
Cloudflare a mis en ligne un test fondé sur la RFC 8509. Le principe consiste à poser deux questions spéciales au résolveur : l’une demande s’il fait confiance à KSK-2024, l’autre s’il ne lui fait pas confiance. Un résultat SERVFAIL n’est pas nécessairement mauvais, car le résolveur doit précisément rejeter l’une des deux requêtes. Le test ajoute des contrôles afin de distinguer une validation correcte d’un service qui ne comprend pas ce mécanisme.
Cette prudence vient de l’expérience de 2018. Lors du premier renouvellement de la clé racine, certains résolveurs avaient perdu l’ancre nouvellement apprise à la suite d’une mise à jour ou d’un déplacement vers une autre machine. L’incident n’avait pas coupé Internet à l’échelle mondiale, mais il avait montré qu’une opération cryptographique correcte pouvait encore échouer au niveau de l’exploitation.
Un exercice grandeur nature avant des changements plus ambitieux
Renouveler une clé limite sa durée d’utilisation et oblige l’écosystème à tester toute la chaîne de distribution : publication, apprentissage, conservation puis retrait. C’est aussi une manière d’entretenir des procédures qui seront indispensables si la racine adopte un jour un autre algorithme. L’ICANN a évoqué une transition future vers ECDSA P-256, dont les signatures sont plus compactes que celles de RSA, mais cette évolution est distincte de la bascule réalisée en octobre.
Cette opération n’est donc pas une réponse directe à l’informatique quantique. Cloudflare expérimente déjà la validation de signatures ML-DSA-44, conçues pour résister à des attaques quantiques, mais sécuriser tout DNSSEC de cette manière exigerait une adoption coordonnée par la racine, les extensions, les domaines et les résolveurs. Le renouvellement actuel vérifie surtout que l’écosystème sait changer de point de départ sans provoquer une cascade d’erreurs.
Les perturbations de grandes plateformes montrent à quel point les couches invisibles peuvent avoir un effet massif : une panne de Cloudflare ou un incident chez Amazon Web Services suffit à rendre de nombreux services injoignables. La différence est qu’ici l’opération était planifiée, progressive et surveillée depuis plusieurs années.
Le calendrier ne s’arrête pas là : l’ancienne KSK-2017 doit être révoquée le 11 janvier 2027.
![image de l'article [#Promo] iPhone Duo 1 To : le prix passe sous les 2 800 € sur Amazon (-10%)](https://static.iphoneaddict.fr/wp-content/uploads/2026/11/promo-iphone-duo-1to-624x492.jpg)
Un commentaire pour cet article :