La racine du système de noms de domaine (DNS) doit changer de clé de signature de clés pour la deuxième fois seulement de son histoire, lorsque KSK-2024, dont l’identifiant de clé est 38696, remplacera KSK-2017, dont l’identifiant est 20326, le 11 octobre 2026. Ce changement concerne particulièrement les opérateurs de résolveurs DNS qui valident DNSSEC, car l’absence de confiance dans la nouvelle clé pourrait rendre des sites sains inaccessibles aux utilisateurs de ces résolveurs.
Qu’est-ce qui change dans la chaîne de confiance ?
DNSSEC utilise des signatures cryptographiques pour vérifier que les enregistrements DNS sont authentiques et n’ont pas été modifiés. La chaîne de confiance commence par une clé publique préalablement approuvée par le résolveur, appelée ancre de confiance, puis s’étend de la racine DNS aux domaines de premier niveau tels que .com, et de ceux-ci aux domaines finaux.
La clé de signature de zone (ZSK) signe les enregistrements de la racine, tandis que la clé de signature de clés (KSK) signe l’ensemble d’enregistrements DNSKEY qui contient les clés de la racine. Le remplacement de la KSK modifie donc le point de départ utilisé par le résolveur pour valider le reste de la chaîne, même si l’algorithme de signature reste le même.
Les opérateurs de sites doivent-ils agir ?
La plupart des opérateurs de sites n’ont pas besoin de modifier les paramètres de leurs domaines. En revanche, les personnes qui gèrent des résolveurs DNSSEC doivent s’assurer que le résolveur fait confiance à KSK-2024 et suivre les instructions du fournisseur du logiciel pour mettre à jour les ancres de confiance si la clé est absente.
Cloudflare indique que les utilisateurs de son DNS, ou des services 1.1.1.1 et Gateway DNS, n’ont aucune action à effectuer, car ses systèmes font confiance à la nouvelle clé. KSK-2024 a été ajoutée à la zone racine depuis le 11 janvier 2025, ce qui a laissé suffisamment de temps aux résolveurs prenant en charge la mise à jour automatique conformément à la RFC 5011 pour la découvrir et l’accepter. Cloudflare a également ajouté la clé aux ancres de confiance intégrées à ses logiciels de résolveur depuis juillet 2024.
Comment tester la préparation
Cloudflare propose un test à l’adresse dnstest.dev/ksk-2024, qui demande au résolveur utilisé par le navigateur s’il fait confiance à la nouvelle clé. Le test s’appuie sur la RFC 8509, qui définit un mécanisme appelé Root Key Trust Anchor Sentinel pour interroger l’état de l’ancre de confiance.
Le test utilise deux noms opposés : is-ta-38696 pour vérifier que la clé est approuvée, et not-ta-38696 pour vérifier qu’elle ne l’est pas. Pour un résolveur qui valide DNSSEC et prend en charge le mécanisme, une réponse réussie au premier nom est valide, tandis que la réponse au second nom est SERVFAIL lorsque KSK-2024 est approuvée.
Une conclusion indéterminée ne signifie toutefois pas nécessairement que la clé est absente ; il est possible que le résolveur ne prenne pas en charge le mécanisme sentinel. De plus, le test effectué dans le navigateur mesure le chemin du résolveur effectivement utilisé par le navigateur et peut être influencé par la fonction Secure DNS ou par un réseau VPN. Il est également possible d’envoyer directement les requêtes à 1.1.1.1 à l’aide de l’outil dig.
Le changement de clé n’est pas un changement d’algorithme
KSK-2017 et KSK-2024 utilisent le même algorithme RSA/SHA-256 ; l’événement d’octobre ne constitue donc pas une transition vers un nouvel algorithme. Le changement se poursuivra jusqu’en 2027, lorsque l’ICANN prévoit de retirer KSK-2017, de la supprimer de la zone racine et d’effacer sa clé privée ; ces étapes sont distinctes de l’arrêt de son utilisation pour signer l’ensemble DNSKEY.
Selon Cloudflare, la rotation périodique des clés limite la durée d’utilisation d’une même clé privée et entraîne les opérateurs à distribuer et à tester les ancres de confiance avant des transitions plus complexes. L’ICANN étudie une future transition vers ECDSA P-256, tandis que la transition vers la cryptographie post-quantique nécessitera elle aussi une nouvelle clé racine et une chaîne de confiance mise à jour.
Pourquoi cette information est-elle importante ?
Le risque concret ne réside pas dans une panne des sites eux-mêmes, mais dans l’échec de la validation par un résolveur DNS qui ne serait pas préparé, ce qui pourrait se traduire pour l’utilisateur par l’impossibilité d’accéder à plusieurs domaines. Le test de la RFC 8509 fournit donc un indicateur pratique du fait que le résolveur conserve la nouvelle clé, mais il dépend de la prise en charge de ce mécanisme par le fournisseur et ne dispense pas les opérateurs d’infrastructure de vérifier les paramètres des ancres de confiance.