La racine DNS change de clé le 11 octobre et coupera les résolveurs figés
Le 11 octobre 2026, la zone racine DNS remplace sa clé de signature KSK-2017 par KSK-2024, la deuxième rotation de l’histoire depuis la signature de la racine en 2010. Tout résolveur validant DNSSEC qui ne fait pas déjà confiance à la nouvelle clé cessera de résoudre l’intégralité des noms : l’enjeu est de repérer, avant dimanche, les résolveurs dont l’ancre de confiance a été figée.
Dimanche 11 octobre 2026. La zone racine DNS change la clé qui signe son jeu de clés : KSK-2024 (key tag 38696) commence à signer, KSK-2017 (key tag 20326) s’arrête, après huit ans de service. Deuxième fois seulement. C’est la deuxième rotation de la clé de signature de la racine depuis que celle-ci a été signée en 2010. Tous les noms. Un résolveur validant DNSSEC qui ne fait pas déjà confiance à la nouvelle clé cesse de résoudre l’intégralité des noms, signés ou non. Pourquoi c’est important : l’immense majorité des résolveurs a récupéré la nouvelle clé automatiquement en février 2025 — mais ceux dont l’ancre de confiance a été figée dans une image, un fichier de configuration ou un équipement jamais mis à jour vont tomber en SERVFAIL dimanche, sans préavis.
Ce qui change exactement, et ce qui ne change pas
La validation DNSSEC est une chaîne. Les clés de votre zone sont attestées par un enregistrement DS chez le parent, les clés du parent par un DS à la racine, et la zone racine est signée par la ZSK (zone signing key), que Verisign fait tourner chaque trimestre. La ZSK est elle-même signée par la KSK (key signing key). Rien ne signe la KSK : un résolveur lui fait confiance parce qu’une copie, l’ancre de confiance, est stockée dans sa propre configuration.
Le 11 octobre, seul ce maillon du sommet change. Avant, le jeu DNSKEY de la racine est signé par KSK-2017 (key tag 20326) ; après, il est signé par KSK-2024 (key tag 38696). Les deux sont des clés RSA/SHA-256 de 2 048 bits (algorithme 8). Tout ce qui se trouve sous la KSK reste en place : le calendrier de la ZSK, les DS des TLD, votre zone. Mais un résolveur qui ne peut pas vérifier le premier maillon ne peut rien vérifier en aval — chaque requête échoue, y compris vers les zones non signées.
Cette copie locale est le point faible du dispositif. Toutes les autres clés de DNSSEC se remplacent en publiant de nouveaux enregistrements. Remplacer la KSK de la racine, c’est modifier un réglage à l’intérieur de chaque résolveur validant de l’Internet, et personne ne possède la liste de ces résolveurs.
Pourquoi la plupart des résolveurs ne verront rien
Le mécanisme qui fait passer les résolveurs s’appelle RFC 5011. Un résolveur qui voit une nouvelle KSK dans le jeu DNSKEY de la racine, signée par une clé à laquelle il fait déjà confiance, démarre un minuteur. Si la nouvelle clé est toujours là après une période de maintien de 30 jours, il l’ajoute à ses ancres et l’écrit sur disque. Pour un résolveur qui tournait le 11 janvier 2025 — date à laquelle KSK-2024 a été publiée dans la racine —, le minuteur a expiré le 10 février 2025. Plus de 95 % des résolveurs qui annoncent leurs ancres aux serveurs racine listent désormais KSK-2024, selon Verisign et l’ICANN.
L’écriture sur disque est précisément l’endroit où le système échoue sans rien dire. Un résolveur dans un conteneur à système de fichiers en lecture seule, ou redéployé chaque semaine depuis une image, redémarre avec l’ancre figée dans l’image et recommence les 30 jours — sans jamais arriver au bout. Les versions récentes d’Unbound, de BIND et de Knot Resolver embarquent les deux clés, donc une image fraîche est saine. Une image construite en 2023 et redémarrée depuis ne l’est pas.
Trois autres situations méritent un regard. Les configurations qui épinglent l’ancre à la main (trusted-keys ou static-key de BIND, trust-anchor au lieu d’auto-trust-anchor-file chez Unbound) ne se mettent jamais à jour, par conception. PowerDNS Recursor n’implémente pas du tout RFC 5011, donc ses ancres arrivent avec le paquet, et un vieux paquet signifie une vieille clé. Enfin, un relais local est exposé s’il valide lui-même : un dnsmasq avec DNSSEC activé, ou un Unbound qui transmet ses requêtes à 8.8.8.8, vérifie toujours les signatures contre sa propre ancre, quoi que Google fasse confiance de son côté.
À quoi ressemble la panne, et comment la réparer
Le symptôme côté application est un SERVFAIL généralisé : tout échoue, signé ou non. Dans les journaux, Unbound rapporte « failed to prime trust anchor » et BIND « no valid signature found » pour le jeu DNSKEY de la racine. La réparation consiste à installer la nouvelle ancre puis à redémarrer : mettre à jour le paquet, ou lancer unbound-anchor, qui récupère les clés courantes depuis le fichier root-anchors.xml de l’IANA. Si des utilisateurs sont déjà à terre et que la réparation prendra du temps, désactiver la validation pendant une heure est un pis-aller défendable — c’est le choix qu’a fait Cloudflare pour le .de.
Avant dimanche, on peut tester un résolveur en une commande. Une requête DNSSEC vers la racine doit renvoyer les deux clés, et une requête vers un nom signé doit se résoudre sans SERVFAIL :
# 1. Le résolveur voit-il les DEUX KSK (20326 et 38696) dans le jeu DNSKEY de la racine ?
dig +dnssec DNSKEY . @127.0.0.1 | grep -E '20326|38696'
# 2. Une validation de bout en bout échoue-t-elle déjà ?
dig +dnssec A cloudflare.com @127.0.0.1 | grep -E 'status:|flags:'
# 3. Pour Unbound : forcer la récupération de l’ancre courante, puis redémarrer.
unbound-anchor -a /var/lib/unbound/root.key && systemctl restart unboundSi la commande 1 ne renvoie pas 38696, le résolveur ne survivra pas à la bascule : c’est le signal d’intervenir maintenant, pas dimanche soir.
Ce que la suite réserve, et pourquoi il ne faut pas s’y fier
La première rotation, prévue le 11 octobre 2017, avait été reportée deux semaines avant la date : sur 11 692 adresses de résolveurs déclarant leurs ancres aux serveurs racine, 577 n’avaient encore que l’ancienne clé. Elle a eu lieu le 11 octobre 2018 à 16 h 00 UTC, et la revue de l’ICANN n’a relevé que « de très rares effets observables mineurs ». La deuxième rotation a elle aussi glissé : la pandémie a perturbé les cérémonies de clés, et une clé de remplacement générée en 2023 a été abandonnée parce que ses modules de sécurité matériels arrivaient en fin de support. KSK-2024 a été générée le 26 avril 2024 et figure dans la racine depuis le 11 janvier 2025, publiée mais pas encore signante.
Le risque le plus discret arrive en janvier 2027, quand KSK-2017 sera publiée avec son bit de révocation. En 2018, la bascule elle-même n’avait fait passer les requêtes DNSKEY des serveurs racine de Verisign que d’environ 15 millions à 75 millions par jour. La révocation de janvier 2019 les a envoyées à 1,15 milliard par jour, environ 7 % du trafic racine mesuré, et le flot ne s’est arrêté qu’au retrait de l’ancienne clé le 22 mars. Personne ne l’avait prédit.
Verdict
Si vous exploitez des résolveurs validants — Unbound, BIND, Knot Resolver en interne, ou des équipements qui valident — exécutez le test de la commande 1 dès cette semaine sur chacun d’eux, en particulier ceux qui tournent dans des conteneurs à système de fichiers en lecture seule ou qui n’ont pas été redéployés depuis 2024. Si vous dépendez d’un équipement propriétaire — passerelle, pare-feu, boîtier DNS — interrogez le constructeur sur la prise en charge de KSK-2024 (key tag 38696) avant dimanche, car c’est la population la plus exposée à une ancre figée en usine. Si vous validez sur un relais local — dnsmasq ou un Unbound en amont de 8.8.8.8 — vérifiez votre propre ancre plutôt que de supposer que l’amont vous sauvera : la validation se fait contre votre configuration, pas contre la sienne. La bascule du 11 octobre sera presque certainement un non-événement pour la majorité — mais pour les résolveurs figés, elle sera un SERVFAIL total, et le seul remède se trouve dans les journaux d’une machine que vous n’avez peut-être pas touchée depuis des années.