veilletech.frCe qui se passe
Le dimanche 11 octobre 2026, la racine du DNS change la clé qui signe sa propre
liste de clés : KSK-2024, key tag 38696, prend la place de KSK-2017, key
tag 20326. C'est seulement le deuxième changement de ce type, après celui de
2018. Cloudflare, qui exploite le résolveur public 1.1.1.1, en profite pour publier
un moyen simple de vérifier qu'un résolveur est prêt.
Pourquoi un résolveur peut tout casser
DNSSEC authentifie une réponse en remontant une chaîne : chaque zone parente
publie un enregistrement DS, l'empreinte de la clé de sa zone fille. La racine
n'a pas de parent. Un résolveur validant part donc d'une clé racine qu'il tient
déjà pour sûre, l'ancre de confiance. La KSK signe l'ensemble DNSKEY de la
racine ; la ZSK que contient cet ensemble signe le reste, dont les DS des
domaines de premier niveau.
Si l'ancre du résolveur ignore KSK-2024 au moment de la bascule, c'est le premier
maillon qui lâche. Le résolveur rejette la racine, et avec elle tous les domaines,
.com comme .fr. Les pannes de .de et de .al, que Cloudflare a documentées,
montraient déjà l'effet à l'échelle d'un seul domaine : des sites en parfait état,
mais injoignables.
Comment la nouvelle clé arrive
La RFC 5011 prévoit une adoption automatique. La nouvelle KSK est publiée à côté de
l'ancienne, qui continue de signer ; le résolveur la remarque, vérifie pendant au
moins 30 jours qu'elle reste présente, puis l'adopte. KSK-2024 figure dans
l'ensemble DNSKEY de la racine depuis le 11 janvier 2025 : tout résolveur qui
applique la RFC 5011 a eu le temps.
Le piège est ailleurs. En 2018, Cloudflare avait vu des résolveurs oublier la clé apprise lors d'une mise à jour logicielle ou d'un changement de machine : l'état appris n'avait pas suivi. C'est la raison pour laquelle Cloudflare a inscrit KSK-2024 dans les ancres intégrées à son logiciel dès juillet 2024.
Tester avant dimanche
Pour la plupart des gens, rien à faire : les utilisateurs de 1.1.1.1, du DNS de Cloudflare ou de Gateway sont prêts. Le cas à vérifier, c'est un résolveur validant que vous exploitez vous-même, sur un serveur ou dans un conteneur.
La RFC 8509 (trust anchor sentinel) permet de poser la question au résolveur avec deux noms signés :
dig @VOTRE_RESOLVEUR root-key-sentinel-is-ta-38696.dnstest.dev. A
dig @VOTRE_RESOLVEUR root-key-sentinel-not-ta-38696.dnstest.dev. A| Requête | KSK-2024 reconnue | KSK-2024 absente |
|---|---|---|
is-ta-38696 |
réponse normale | SERVFAIL |
not-ta-38696 |
SERVFAIL |
réponse normale |
Le SERVFAIL sur not-ta est donc le bon signe. Si les deux noms répondent
normalement, le résolveur ne valide pas ou ne gère pas la RFC 8509 : le test est
alors non concluant, il ne prouve pas que la clé manque. La page
dnstest.dev/ksk-2024 fait la même vérification pour
le résolveur de votre navigateur, avec des contrôles en plus — un VPN ou le DNS
sécurisé du navigateur peuvent toutefois changer le résolveur testé.
Si la clé manque : appliquer les consignes de l'éditeur du résolveur et celles de l'ICANN pour mettre à jour les ancres.
Et après
La bascule conserve l'algorithme RSA/SHA-256. En 2027, l'ICANN prévoit de révoquer KSK-2017, de la retirer de la zone racine et de détruire sa clé privée. Un passage à ECDSA P-256 est proposé à part, et l'arrivée d'une cryptographie post-quantique à la racine exigera un nouveau roulement : celui-ci sert aussi de répétition.
Source : The keys to the Internet change on October 11. Are you ready?, blog Cloudflare, 6 octobre 2026.