La racine DNSSEC bascule sur KSK-2024 le 11 octobre 2026 et les résolveurs obsolètes décrocheront

11 octobre 2026. La KSK-2024 prend le relais de signature de la racine DNSSEC. Janvier 2027. L’ancienne clé, la KSK-2017, quitte l’ensemble actif. 38696. C’est le key tag de la nouvelle clé que tout résolveur validant doit connaître. L’événement est rare — le précédent remonte à 2018 — et son mode de défaillance est brutal : un résolveur à l’ancre de confiance périmée ne perd pas un site, il perd toute résolution signée d’un coup, alors que la connectivité réseau reste intacte.

Ce qui change exactement

DNSSEC ajoute des signatures cryptographiques aux réponses DNS. Un résolveur validant s’en sert pour vérifier qu’une réponse est authentique et n’a pas été altérée en transit. Au sommet de cette hiérarchie se trouve la clé de signature de zone racine (KSK), qui joue le rôle d’ancre de confiance mondiale.

La KSK-2017, en service depuis le dernier roulement, porte le key tag 20326. Sa remplaçante, la KSK-2024, porte le key tag 38696. La nouvelle clé a été publiée très en amont pour que les résolveurs utilisant le mécanisme d’ancrage automatique RFC 5011 puissent l’apprendre sans interruption.

Le calendrier est verrouillé par l’IANA :

Une précision rassurante : le roulement remplace la paire de clés, pas l’algorithme. La signature continue d’utiliser RSA avec SHA-256. Rien à changer côté algorithme, donc, pour les résolveurs déjà conformes.

Pourquoi cet événement n’est pas anodin

Le dernier roulement complet de la racine remonte au 11 octobre 2018. À l’époque, c’était une première mondiale : jamais la clé au sommet de la chaîne de confiance DNSSEC n’avait été remplacée en production. L’opération s’était déroulée sans interruption majeure, mais elle avait mobilisé la communauté pendant des mois.

Cette fois, ICANN a renouvelé son avertissement fin juillet 2026. Selon l’organisation, plus de 95 % des résolveurs déclarants reconnaissent déjà la nouvelle clé. Ce chiffre rassure, mais il ne couvre ni les appliances de réseau héritées, ni les résolveurs isolés, ni les images de firmware non maintenues, ni les installations dont l’ancre de confiance est gérée à la main.

La cérémonie de clé racine n’est pas qu’une formalité. La KSK Ceremony 62 s’est tenue le 12 août 2026 au centre de gestion des clés d’ICANN, à El Segundo en Californie. Elle illustre le niveau de contrôle physique et procédural qui entoure cette clé unique.

L’ampleur de l’infrastructure derrière la clé

La clé qui bascule le 11 octobre n’est pas un objet abstrait. Elle signe la zone racine, au sommet d’un système de serveurs racine qui comptait, au 30 août 2026, 2 004 instances opérationnelles réparties entre douze opérateurs indépendants. Chaque résolveur validant de la planète remonte cette chaîne jusqu’à cette clé unique, quel que soit son opérateur ou son pays.

Cette centralisation apparente est en réalité le point d’entrée d’un modèle décentralisé : les douze opérateurs de serveurs racine servent la même zone signée, et tout résolveur qui la valide dépend de la même ancre. C’est précisément ce qui rend le roulement à la fois sûr — la redondance absorbe les incidents locaux — et exigeant, car une erreur d’ancre se répercute partout en même temps.

Le mode de défaillance silencieux

Le danger du roulement n’est pas le chaos généralisé, c’est l’échec local et total. Un résolveur validant qui ne fait pas confiance à la nouvelle KSK ne pourra plus valider la racine. Comme la chaîne DNSSEC démarre là, l’impact s’étend bien au-delà d’un domaine signé précis.

Les symptômes sont trompeurs : de nombreux sites sans rapport échouent en même temps ; les applications signalent « serveur introuvable » alors que le réseau est connecté ; les réponses SERVFAIL se multiplient ; les adresses IP connues restent joignables pendant que les noms de domaine échouent. Vu de l’utilisateur, c’est une panne Internet ; vu du réseau, c’est un problème d’ancre de confiance que seul un contrôle du résolveur révèle.

La gravité tient à ce que l’échec est binaire. Il n’y a pas de dégradation progressive : le 11 octobre, soit le résolveur connaît le tag 38696, soit il décroche. Les résolveurs qui ont mis à jour leur ancre automatiquement ne remarqueront rien.

Qui doit agir, et qui peut ne rien faire

Une précision d’abord : le roulement ne concerne que les résolveurs qui valident DNSSEC. Un résolveur qui ne vérifie pas les signatures — la configuration par défaut de nombreux réseaux — continuera de fonctionner normalement le 11 octobre, car il ne consulte jamais la clé racine pour valider. La panne éventuelle ne touche que ceux qui valident sans connaître la nouvelle clé.

Utilisateurs finaux. Si votre routeur reçoit le DNS automatiquement de votre opérateur, ou si vous utilisez un service public maintenu comme Cloudflare, Google Public DNS ou Quad9, l’opérateur du résolveur porte la responsabilité de la mise à jour. Inutile de ré-enregistrer un domaine ou de changer de mot de passe à cause du roulement.

Entreprises, FAI et laboratoires. Vous devez vérifier l’état de préparation si vous exploitez un résolveur récursif qui valide DNSSEC, en particulier quand il utilise une ancre de confiance configurée manuellement, qu’il tourne sur une version ancienne de BIND, Unbound, PowerDNS Recursor ou Knot Resolver, qu’il est resté hors ligne longtemps, qu’il est embarqué dans un pare-feu ou une appliance non maintenue, ou qu’il ne peut pas écrire ses mises à jour de clé automatiques.

ICANN recommande de localiser le tag 38696 dans le fichier d’ancre de confiance du résolveur. Les noms varient : bind.keys pour BIND, root.key pour Unbound et PowerDNS Recursor, root.keys pour Knot Resolver.

La vérification en trois commandes

Le test le plus simple confirme d’abord que la validation DNSSEC est active. Remplacer DNS_ADDRESS par l’adresse IPv4 ou IPv6 du résolveur :

dig @DNS_ADDRESS dnssec-failed.org A +dnssec

Le domaine de test est volontairement invalide. Un statut SERVFAIL signifie que le résolveur a détecté la mauvaise signature et valide donc DNSSEC. Un statut NOERROR signifie qu’il a renvoyé la donnée sans valider. Ce test prouve que la validation fonctionne, mais pas que la KSK-2024 est stockée.

Le pas décisif est de chercher le tag 38696 dans l’état de l’ancre de confiance et de relire les journaux du résolveur :

grep -c "38696" /var/lib/unbound/root.key

Une valeur supérieure à zéro indique que la clé est connue. Mettre à jour ou redémarrer le service uniquement selon la procédure du fournisseur — une édition improvisée du fichier d’ancre peut créer la panne qu’on cherchait à éviter.

Verdict

Si vous exploitez un résolveur validant, consacrez dix minutes avant le 11 octobre 2026 : confirmez la présence du tag 38696 dans le fichier d’ancre, notez la version de votre résolveur et préparez un résolveur de secours déjà testé avec le même niveau de validation DNSSEC. C’est un contrôle trivial qui évite un incident de résolution complet.

Si vous dépendez d’un résolveur public ou d’un opérateur, ne touchez à rien. Le seul réflexe utile est de retenir la date : le 11 octobre, si de nombreux sites cessent de s’ouvrir alors que la connectivité IP fonctionne, placez le résolveur en tête de la liste des suspects plutôt que de réinitialiser la box.

Références

• IANA — Trust anchors and rollovers (calendrier officiel)
• ICANN — Preparing for the Root Zone KSK Rollover, 27 juillet 2026
• ICANN — Press release, « ICANN Announces Next Major Internet Security Update », 20 mai 2026
• ICANN — KSK Rollover information page
• DNS Benchmark — DNSSEC 2026: Prepare for the Root KSK Rollover