Ce qui a changé le 11 octobre 2026
DNSSEC repose sur une seule racine de confiance : la clé de signature de clé (KSK) de la zone racine. Chaque résolveur validant en garde une copie locale, appelée ancre de confiance, et vérifie tout le reste à partir d'elle. D'après l'IANA, KSK-2024 (key tag 38696) a été publiée dans la zone racine le 11 janvier 2025, puis a commencé à signer la racine le 11 octobre 2026, à la place de KSK-2017 (key tag 20326).
Le 15 octobre 2026, l'ICANN a annoncé que le changement de clé s'était terminé comme prévu. L'annonce mentionne des signalements sur un nombre limité de systèmes et précise que l'ICANN évalue encore s'ils sont liés au changement : elle ne donne ni chiffre ni cause, et ce guide n'en avance pas. Le calendrier n'est pas clos : l'IANA prévoit la révocation de KSK-2017 le 11 janvier 2027, puis son retrait de la zone le 22 mars 2027.
Ce qu'il faut retenir
- La clé à chercher — KSK-2024, key tag 38696, algorithme 8 (RSA/SHA-256). L'ancienne, KSK-2017, porte le key tag 20326.
- Le symptôme — un résolveur qui ne fait confiance qu'à 20326 ne peut plus valider la racine. Verisign et l'ICANN préviennent qu'il échoue alors à résoudre, que le nom demandé soit signé ou non.
- Le mécanisme normal — la RFC 5011 permet à un résolveur d'adopter seul une nouvelle clé après l'avoir observée 30 jours, à condition qu'il tourne et puisse écrire son fichier d'ancre.
- Les cas à risque — une image système ou un instantané plus ancien que la clé, un fichier d'ancre en lecture seule, une ancre statique dans dnsmasq ou dans BIND.
- Ce qui ne change pas — l'enregistrement DS de votre domaine chez le registre : le changement concerne la clé de la racine, pas celle de votre zone.
- La suite du calendrier — révocation de KSK-2017 prévue le 11 janvier 2027, retrait le 22 mars 2027. Un résolveur qui fait déjà confiance à 38696 valide la racine signée par cette clé.
Propriétaire de domaine ou administrateur de serveur : qui doit agir
Deux rôles se confondent souvent dans les tickets. Le propriétaire d'un domaine signé publie un enregistrement DS chez son registre, qui désigne la clé de SA zone. Ce DS ne dépend pas de la clé de la racine : il n'y a rien à modifier pour ce changement, ni dans la zone de votre-domaine.com, ni chez votre bureau d'enregistrement. Si vous gérez seulement vos enregistrements (voir ajouter un enregistrement DNS), vous n'êtes pas concerné.
L'administrateur d'un serveur qui fait tourner un résolveur validant, lui, l'est. Unbound derrière une messagerie, BIND sur un serveur de supervision, Knot Resolver dans un conteneur, systemd-resolved avec DNSSEC activé, dnsmasq ou Pi-hole avec la validation cochée : chacun porte sa propre ancre. Sur un VPS dont vous avez l'accès root, cet administrateur, c'est vous. Un serveur qui transmet ses requêtes à un résolveur public sans valider lui-même dépend de l'ancre de ce résolveur, pas de la sienne.
Prérequis du diagnostic
Prévoyez dix minutes et un accès root ou sudo au serveur. Deux outils suffisent : dig et delv, fournis sur Debian et Ubuntu par le paquet bind9-dnsutils (sudo apt install bind9-dnsutils), et sur AlmaLinux ou Rocky Linux par bind-utils. Aucune ressource particulière n'est nécessaire : les requêtes se comptent en kilooctets.
Notez l'adresse d'écoute de votre résolveur, en général 127.0.0.1, ou 127.0.0.53 pour systemd-resolved, et gardez l'adresse d'un résolveur public validant pour comparer, par exemple 9.9.9.9. Les sorties décrites ci-dessous sont des exemples de forme, pas des mesures de votre serveur : seuls les champs nommés comptent. Les tests portent sur la racine et sur com., deux zones signées : ils ne dépendent d'aucun domaine en particulier.
Diagnostiquer votre résolveur en sept étapes
Identifier le résolveur qui répond
cat /etc/resolv.confdonne l'adresse interrogée par le système,resolvectl statusindique si systemd-resolved s'intercale, etsudo ss -lunp 'sport = :53'nomme le processus qui écoute sur le port 53 :unbound,named,kresd,dnsmasqoupihole-FTL. C'est ce processus que vous allez examiner.Interroger la racine avec dig +dnssec
Lancez
dig +dnssec . SOA @127.0.0.1, puisdig +dnssec com. SOA @127.0.0.1. Regardez deux champs de l'en-tête :status:etflags:. Unstatus: NOERRORaccompagné du drapeauadsignifie que la réponse a été validée. Unstatus: SERVFAILsur la racine elle-même est le signe le plus net d'une ancre périmée.Isoler la validation avec +cd
dig +dnssec +cd com. SOA @127.0.0.1demande au résolveur de répondre sans valider (checking disabled). Si cette requête revient enNOERRORalors que la précédente échoue enSERVFAIL, le réseau et les serveurs amont fonctionnent : c'est la validation DNSSEC qui bloque, donc l'ancre ou l'horloge.Comparer avec un résolveur public validant
dig +dnssec com. SOA @9.9.9.9doit répondreNOERRORavecad. Si le résolveur public valide et le vôtre non, le problème est local. Vérifiez au passage l'heure du serveur avectimedatectl: une horloge décalée fait elle aussi échouer la vérification des signatures, et produit le même SERVFAIL.Voir quelle clé signe la racine
dig +dnssec +multi . DNSKEY @9.9.9.9affiche les clés publiées. Celles de flag257sont les KSK ; avec+multi, dig ajoute leurkey iden commentaire. Dans la phase actuelle, KSK-2017 reste publiée, mais la signature (RRSIG) du jeu de clés porte le key tag 38696 : c'est cette clé que votre ancre doit connaître.Lire l'ancre réellement chargée
Unbound :
sudo grep 'id = 38696' /var/lib/unbound/root.key(chemin Debian ; ailleurs,unbound-checkconf -o auto-trust-anchor-filedonne le vôtre) doit renvoyer une ligne marquéeVALID. BIND :sudo rndc secroots -doit lister./RSASHA256/38696 ; managed, etsudo rndc managed-keys statusune entréekeyid: 38696suivie detrusted since. Knot Resolver : appeleztrust_anchors.summary()depuis sa console de contrôle. dnsmasq : cherchez une lignetrust-anchor=.,38696,8,2,…dans la configuration chargée.Confirmer avec delv
delv @127.0.0.1 com. SOAvalide lui-même la réponse et affiche; fully validatedquand la chaîne est complète. Attention : delv utilise l'ancre compilée dans son propre binaire, pas celle de votre résolveur. Un delv ancien peut donc échouer seul : mettez à jour le paquet avant d'en tirer une conclusion sur le résolveur.
Où vit l'ancre de confiance, résolveur par résolveur
Faites défiler le tableau
| Résolveur | Où regarder | Mise à jour de la clé |
|---|---|---|
| Unbound | Directive `auto-trust-anchor-file` (Debian : `/var/lib/unbound/root.key`) | RFC 5011 si le fichier et son répertoire sont inscriptibles, sinon `unbound-anchor` |
| BIND | `rndc secroots -` et `managed-keys.bind` ; ancre intégrée avec `dnssec-validation auto` | RFC 5011 avec `auto`, `initial-key` ou `initial-ds` ; aucune avec `static-key` |
| Knot Resolver | `trust_anchors.add_file()` en v5, `dnssec/trust-anchors-files` en v6 | RFC 5011, sauf si le fichier est déclaré en lecture seule |
| systemd-resolved | Ancre intégrée au binaire ; fichiers `*.positive` de `/etc/dnssec-trust-anchors.d/` | Aucune par le DNS : il faut un paquet systemd à jour |
| dnsmasq | Lignes `trust-anchor=` de la configuration chargée | Aucune : ligne statique à éditer à la main |
| Pi-hole v6 | `/etc/pihole/dnsmasq.conf`, généré par FTL | Réécrit par FTL, qui inscrit les clés 20326 et 38696 |
| delv (outil) | Ancre compilée dans le binaire | Mise à jour du paquet qui le fournit |
Corriger selon votre résolveur
Unbound : rafraîchir l'ancre
Mettez d'abord le système à jour (
sudo apt update && sudo apt upgrade). Sur Debian, le paquetdns-root-datafournit/usr/share/dns/root.key, et le script de démarrage d'Unbound recopie ce fichier vers/var/lib/unbound/root.keylorsqu'il est plus récent ; la version2024071801~deb12u1livrée pour Debian 12 contient déjà KSK-2024. Forcez ensuite la vérification avecsudo -u unbound unbound-anchor -a /var/lib/unbound/root.key -v, puissudo systemctl restart unbound. La clé intégrée àunbound-anchorinclut KSK-2024 depuis Unbound 1.21.0.Unbound : rendre la RFC 5011 possible
Si la clé manque encore, vérifiez que l'utilisateur
unboundpeut écrire le fichier ET son répertoire : la documentation l'exige pour créer un fichier temporaire.ls -ld /var/lib/unbound /var/lib/unbound/root.keysuffit à le voir. Un fichier monté en lecture seule dans un conteneur bloque la mise à jour automatique sans erreur visible côté client.BIND : auto ou ancre déclarée
Avec
dnssec-validation auto;, BIND part de l'ancre fournie avec le logiciel et la tient à jour par RFC 5011 dansmanaged-keys.bind. Mettez à jour le paquet, vérifiez quemanaged-keys-directoryest inscriptible parnamed, puis lancezsudo rndc managed-keys refresh. Avecdnssec-validation yes;et une ancre déclarée à la main, ajoutez dans le bloctrust-anchorsla ligne. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";et retirez toute ancrestatic-keyqui ne connaît que 20326.Knot Resolver : vérifier le fichier d'ancre
Mettez à jour le paquet, puis regardez comment le fichier d'ancre est déclaré. En lecture seule (second argument
truedetrust_anchors.add_file()en v5,read-only: trueen v6), le résolveur ne le modifie jamais : c'est le paquet de votre distribution qui doit apporter la clé. Sinon, vérifiez quekresdpeut écrire le fichier. La documentation précise qu'en l'absence de fichier, le résolveur tente d'amorcer lui-même l'ancre de la racine.systemd-resolved : mettre à jour systemd
systemd-resolved ne met pas à jour son ancre par le DNS : seule une mise à jour du paquet apporte la nouvelle clé. Le code amont l'intègre notamment depuis systemd 256.12 et 257.4, et le paquet
systemd-resolvedactuel de Debian 12 la contient aussi. Vérifiez/etc/dnssec-trust-anchors.d/: un fichier*.positivequi déclare une clé racine désactive l'ancre intégrée. Retirez-le ou ajoutez-y la clé 38696, puissudo systemctl restart systemd-resolvedetresolvectl flush-caches.dnsmasq : ajouter la ligne statique
dnsmasq n'applique pas la RFC 5011 : l'ancre est une ligne fixe. Ajoutez
trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16à côté de la ligne 20326, puis redémarrez le service. Sur Debian 12, le fichier/usr/share/dnsmasq-base/trust-anchors.confdu paquetdnsmasq-base2.90-4~deb12u2 ne contient que la clé 20326, alors que celui de Debian 13 contient les deux : vérifiez quel fichier votre configuration charge réellement. Pi-hole v6 écrit lui-même les deux lignes dans/etc/pihole/dnsmasq.confquand la validation DNSSEC est activée.Automatiser pour la prochaine fois
Une ancre ne se périme que sur un serveur qui ne se met plus à jour. Activez les mises à jour de sécurité automatiques des paquets de résolveur (voir mises à jour automatiques sur Debian et Ubuntu) et ajoutez à votre supervision une sonde
dig +dnssec com. SOA @127.0.0.1qui alerte surSERVFAIL. Si votre DNS local passe par Pi-hole, le guide Pi-hole v6 sur VPS montre comment placer Unbound en amont.
Après la correction : ce qu'il faut surveiller
Une fois le drapeau ad revenu dans les réponses, trois points méritent une vérification.
Les images et les instantanés d'abord. Une machine restaurée à partir d'une sauvegarde ancienne repart avec le fichier d'ancre de l'époque. Si ce fichier ne connaît que 20326, la RFC 5011 ne peut plus la rattraper : elle n'accepte une nouvelle clé que si le jeu de clés est signé par une clé déjà approuvée, et la racine n'est plus signée par 20326. Il faut alors rafraîchir l'ancre à la main, comme ci-dessus.
Les images de conteneurs ensuite. Une image construite avec une ancre statique la garde à chaque redéploiement : reconstruisez-la à partir d'une base à jour.
La révocation enfin. Le 11 janvier 2027, KSK-2017 doit être publiée avec le bit de révocation. Un résolveur qui suit la RFC 5011 la marquera comme révoquée : dans le fichier d'Unbound, la ligne 20326 passera à l'état REVOKED. C'est l'état attendu, pas une panne.
Ne coupez pas la validation pour faire taire l'erreur
Passer à dnssec-validation no, val-permissive-mode: yes ou DNSSEC=no fait disparaître le SERVFAIL, mais retire aussi toute protection contre les réponses falsifiées. Corrigez l'ancre, puis testez. Ne collez jamais une clé trouvée sur un forum : la source qui fait foi est https://data.iana.org/root-anchors/root-anchors.xml, dont la signature se vérifie avec root-anchors.p7s et icannbundle.pem, publiés au même endroit par l'IANA. Le condensé SHA-256 de KSK-2024 y figure : 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16.
Dépannage : les messages que vous verrez
Les messages ci-dessous sont repris du code source ou de la documentation des logiciels concernés. Ils permettent de distinguer une ancre périmée d'un problème réseau, d'une horloge décalée ou d'un outil de diagnostic lui-même trop ancien. Pour Unbound, augmentez d'abord la précision des journaux avec val-log-level: 2 dans la section server:, puis redémarrez : chaque requête refusée sera journalisée avec sa raison et le serveur qui a fourni la donnée fautive.
Messages d'erreur et remèdes
failed to prime trust anchor -- DNSKEY rrset is not secure(journal d'Unbound, suivi de. DNSKEY IN) — Unbound a obtenu les clés de la racine mais n'a pas pu les valider avec son ancre : ancre périmée ou horloge fausse. Rafraîchissezroot.key.failed to prime trust anchor -- could not fetch DNSKEY rrset— Unbound n'obtient même pas les clés de la racine : réseau, pare-feu ou fragmentation UDP, pas l'ancre. Testezdig +dnssec . DNSKEYvers le serveur amont.status: SERVFAILavec+dnssec,NOERRORavec+cd— signature d'un échec de validation. Avecede: yesdans Unbound, le client reçoit en plus un code d'erreur étendu (RFC 8914).resolution failed: broken trust chainouno valid RRSIG(delv) — delv n'a pas pu remonter jusqu'à une ancre valide. Vérifiez d'abord que delv lui-même est à jour.; initializing manageddansrndc secroots -— BIND connaît la clé mais ne l'a jamais confirmée par une requête de rafraîchissement. Lancezrndc managed-keys refreshet vérifiez les droits surmanaged-keys-directory.unbound-anchorsort avec le code 0 sans rien changer — selon sa page de manuel, 0 signifie aussi bien « aucune mise à jour nécessaire » qu'« erreur ». Relancez avec-vet relisez le fichier.
En résumé
Le changement de clé de la racine ne demande rien aux propriétaires de domaines, ni aux serveurs dont les paquets suivent les mises à jour. Il pénalise les résolveurs figés : image ancienne, fichier d'ancre non inscriptible, ancre statique dans dnsmasq ou BIND. Trois gestes suffisent à trancher : dig +dnssec com. SOA contre votre résolveur, la même requête avec +cd, puis la lecture de l'ancre chargée. Gardez la date du 11 janvier 2027 en tête : la révocation de KSK-2017 apparaîtra dans vos fichiers d'ancre, et c'est un état attendu. Sur un serveur dont vous avez l'accès root, ce contrôle prend dix minutes et se planifie une fois pour toutes dans votre supervision.
