Le changement de clé racine DNSSEC a eu lieu : les vérifications à effectuer

L’étape prévue pour octobre 2026 ne correspond pas à un changement d’opérateur de la zone racine DNS. Il s’agit d’un rollover de la clé de signature de clé (KSK) utilisée par DNSSEC : ICANN et l’IANA ont planifié cette transition progressive, amorcée en 2024. KSK-2024 porte l’étiquette de clé 38696. Il s’agit d’un changement de clé cryptographique, et non d’un transfert de responsabilité opérationnelle.

La distinction est importante. La zone racine se situe au sommet de la hiérarchie DNS. La clé cryptographique concernée sert d’ancre de confiance aux résolveurs validateurs pour vérifier la zone racine et, par son intermédiaire, la chaîne DNSSEC. Présenter le rollover comme un changement d’opérateur confond le renouvellement des clés avec la gouvernance et l’infrastructure.

Le calendrier d’ICANN prévoyait le début de la signature avec la nouvelle clé le 11 octobre 2026, puis le retrait de KSK-2017 en janvier 2027. Les conséquences pratiques concernent surtout les systèmes qui valident DNSSEC avec une configuration ancienne ou gérée manuellement; les administrateurs peuvent vérifier que leur résolveur dispose de l’ancre de confiance prévue.

Le DNS organise les noms de domaine selon une hiérarchie. À son sommet se trouve la zone racine, qui publie des renvois vers les domaines de premier niveau — par exemple .com, .org ou les extensions nationales — ainsi que vers les serveurs qui en sont responsables. Un serveur racine ne conserve pas l’adresse IP de chaque site web : il oriente le résolveur vers l’étape suivante de la recherche.

Lorsqu’un résolveur récursif ne trouve pas de réponse dans son cache, il peut interroger l’une des identités racine. La réponse le dirige vers le serveur du TLD concerné ; le résolveur poursuit ensuite vers les serveurs faisant autorité pour le domaine. Si l’information est déjà en cache, la requête peut être résolue sans atteindre la racine : celle-ci n’intervient donc pas à chaque visite d’une page web.

Il faut également distinguer les 13 identités racine nommées, de A à M, des machines physiques qui les desservent. Le système est réparti entre de nombreuses instances et des opérateurs indépendants ; ICANN décrit 13 identités gérées par 12 opérateurs et plus de 1 500 serveurs individuels. La redondance et le routage anycast permettent de traiter les requêtes depuis plusieurs emplacements, mais ne font pas de chaque instance un opérateur distinct et ne suppriment pas la coordination de la zone racine.

DNSSEC ajoute des signatures cryptographiques pour permettre à un résolveur validateur de vérifier l’authenticité et l’intégrité des données DNS. La KSK racine valide l’ensemble DNSKEY de la zone racine ; d’autres clés de cette zone interviennent dans la chaîne qui vérifie les renvois vers les domaines de premier niveau. La nouvelle clé ne modifie ni la hiérarchie des domaines ni les enregistrements des sites : elle renouvelle le point de départ cryptographique de cette vérification.

KSK-2024 a été publiée dans la zone racine le 11 janvier 2025, afin que les résolveurs compatibles avec la mise à jour automatique des ancres de confiance puissent l’apprendre. ICANN avait prévu que la nouvelle clé commence à signer la zone racine le 11 octobre 2026. Le début de la signature et le retrait définitif de KSK-2017 sont deux étapes distinctes.

Ce remplacement ne constitue pas une migration vers un algorithme cryptographique différent. Cloudflare indique que KSK-2017 et KSK-2024 utilisent RSA/SHA-256. Un remplacement de clé avec le même algorithme ne correspond donc pas à une migration vers la cryptographie post-quantique; un changement d’algorithme constitue un processus distinct.

La plupart des personnes n’ont rien à faire sur leur téléphone, leur ordinateur ou leur routeur. Celles qui utilisent les résolveurs administrés par leur fournisseur d’accès à Internet ou par un service DNS public comptent sur ces opérateurs pour tenir à jour les logiciels et les ancres de confiance. Il n’est pas nécessaire de changer de serveur DNS du seul fait du renouvellement de la KSK.

Le travail incombe principalement aux administrateurs de résolveurs récursifs qui valident DNSSEC, surtout lorsqu’ils gèrent des ancres manuelles, exécutent des logiciels anciens ou administrent des équipements restés hors ligne longtemps. Si un résolveur ne fait pas confiance à KSK-2024, il peut rejeter la validation de réponses pourtant correctement signées. Pour les personnes qui utilisent ce résolveur, certains noms peuvent alors ne plus être résolus, même si les sites et leurs serveurs fonctionnent.

Une réponse SERVFAIL ne prouve pas, à elle seule, que la nouvelle clé est absente : d’autres problèmes de configuration ou de validation peuvent produire la même réponse. Il faut vérifier l’état de confiance réellement utilisé par le résolveur, et pas seulement la présence de la clé dans une réponse DNS. ICANN associe l’étiquette 38696 à KSK-2024. Les administrateurs doivent la comparer aux procédures et aux fichiers d’ancres de leur logiciel, et ne pas supprimer manuellement l’ancienne clé en dehors du calendrier officiel.

Le renouvellement de la KSK concerne la validation cryptographique de DNSSEC. La latence d’une requête dépend notamment de l’emplacement du résolveur, des itinéraires Internet et de la présence ou non de la réponse dans le cache ; le rollover ne permet pas, à lui seul, de conclure à une amélioration générale de la latence.

La fonction de sécurité de DNSSEC est d’aider à détecter les réponses DNS non authentiques ou modifiées ; le protocole ne chiffre pas à lui seul les requêtes et ne masque pas le nom demandé. Le changement de clé préserve la capacité de valider la zone racine avec une clé renouvelée, mais ne remplace pas les autres mesures de sécurité : maintenance du résolveur, protection de ses systèmes ou chiffrement du transport DNS lorsque cela convient.

Le processus met aussi à l’épreuve la coordination entre la publication d’une nouvelle clé, son adoption par les résolveurs et le retrait de l’ancienne. Le premier rollover de la KSK racine a eu lieu en 2018 ; la transition actuelle est la deuxième. La continuité dépend de la présence d’une ancre valide dans les systèmes validateurs, tandis que l’architecture distribuée et les caches renforcent d’autres étapes de la résolution. Ces mécanismes sont complémentaires, et non interchangeables.

Si vous administrez un résolveur qui valide DNSSEC, vérifiez que sa configuration fait confiance à KSK-2024 (étiquette de clé 38696) et que le mécanisme de mise à jour des ancres fonctionne. Consultez la documentation de la version logicielle installée et l’état persistant du service : la présence de la clé dans la zone publique ne garantit pas que le logiciel l’a intégrée comme ancre de confiance.

Pour les équipements qui utilisent des résolveurs tiers, il est raisonnable de consulter l’état du service ou les avis du fournisseur en cas d’erreurs de résolution persistantes. Ne modifiez pas les enregistrements d’un domaine et ne désactivez pas DNSSEC comme première réponse à SERVFAIL sans déterminer où la validation échoue. Le problème peut venir du résolveur, d’une zone particulière ou d’une autre partie de la chaîne.

La prochaine étape du calendrier d’ICANN est le retrait de KSK-2017, prévu en janvier 2027. D’ici là, les administrateurs et fournisseurs doivent suivre les instructions officielles et maintenir leurs mises à jour de sécurité habituelles. Pour les utilisateurs finaux, le message est simple : inutile de reconfigurer votre connexion à cause de ce rollover ; la modification concerne l’infrastructure qui valide les requêtes.