Résumé

  • Le rapport d’APNIC combine une lecture de juillet des signaux de résolveurs RFC 8145 et de nouveaux tests RFC 8509 sur des terminaux. Les taux d’environ 90 % et 70 % décrivent des voies d’observation différentes et ne peuvent être soustraits ni moyennés.
  • Le tableau de réseaux est une liste de points à vérifier, non une note de préparation d’un fournisseur ou une estimation du nombre de clients exposés. Les opérateurs doivent contrôler leurs propres résolveurs validateurs.

Analyse

Un pourcentage doit préciser ce qu’il observe

Deux jours avant une modification planifiée de la clé DNSSEC racine, un taux de préparation paraît être le chiffre décisif. Si la plupart des résolveurs possèdent la clé de remplacement, la transition devrait réussir ; si trop peu l’ont, quelqu’un devrait l’arrêter. Mais un signal de résolveur, un test effectué depuis le réseau d’un utilisateur et les personnes qui dépendent de ce réseau ne sont pas des unités interchangeables.

Dans son rapport du 9 octobre, rédigé le 8, APNIC juxtapose deux observations liées à KSK-2024. La première relève de RFC 8145 : un résolveur validateur peut signaler les identifiants des clés qu’il fait confiance dans des requêtes visibles par les opérateurs des serveurs faisant autorité. La seconde utilise le Root Key Trust Anchor Sentinel de RFC 8509. Un test passe par un terminal, puis la réponse permet d’inférer un état de confiance du résolveur. Même clé, même échéance, mais pas le même objet mesuré.

La description RFC 8145 comporte une nuance importante. APNIC lit son graphique de juillet comme indiquant qu’environ 90 % des résolveurs déclarants avaient ajouté KSK-2024. La mise à jour de Verisign du 28 juillet indique que l’adoption parmi les sources émettant ces signaux avait dépassé 95 % après environ 500 jours. APNIC attribue son graphique à Verisign, mais les textes publiés ne précisent pas une date d’extraction et une définition communes qui permettraient d’aligner ces chiffres. Ils peuvent correspondre à des coupes ou résumés différents ; les éléments disponibles ne permettent pas de trancher.

C’est une lacune documentaire à conserver, pas la preuve qu’une mesure a échoué.

Le chiffre de 70 % est encore moins comparable directement. APNIC indique que son système de mesure financé par la publicité réalisait environ 16 millions de tests de terminaux par jour. Environ 6 millions situaient le terminal derrière un résolveur récursif validant DNSSEC ; quelque 1,8 million fournissaient un signal clair de prise en charge de RFC 8509. Parmi les tests qui semblaient prendre en charge le mécanisme, environ 70 % indiquaient que KSK-2024 était chargée. Ce dénominateur est le sous-ensemble testé avec un signal clair, et non tous les tests, tous les résolveurs validateurs ou tous les internautes.

Deux mécanismes, deux questions

RFC 8145 permet à un résolveur validateur d’indiquer les identifiants de clés présents dans sa chaîne de confiance. La norme définit deux moyens facultatifs de signalement, par option EDNS ou par requête spéciale. Pour la racine, les opérateurs de l’infrastructure autoritaire peuvent observer ces signaux. Les données montrent comment évolue l’état déclaré parmi les sources qui les envoient.

Elles ne disent pas combien de foyers, d’entreprises ou de services dépendent de chaque résolveur. Certains résolveurs récursifs desservent une vaste population ; d’autres un seul équipement ou une seule organisation. Des relais intermédiaires peuvent également changer ce que voit l’opérateur de la racine. Un pourcentage de signaux déclarés répond donc à une question sur ces signaux, pas à une mesure de l’exposition des utilisateurs.

RFC 8509 emprunte un autre chemin. Le test envoie des requêtes DNS spécialement formées ; un résolveur validateur compatible réagit selon que la clé racine est ou non approuvée. APNIC utilise une plateforme de mesure par publicité pour faire passer ces requêtes par des terminaux. L’observation se rapproche du chemin de résolution rencontré par un terminal testé, mais dépend toujours de la compatibilité du résolveur et de la capacité à classer la réponse. Elle n’identifie pas tous les résolveurs derrière le terminal et ne dénombre pas les utilisateurs qui les partagent.

Le test RIPE Atlas du 5 octobre ajoute un troisième point de vue, pas une vérification universelle. Des sondes réparties dans 2 900 systèmes autonomes ont produit 1 230 comportements compatibles avec le chargement de la nouvelle clé et 47 compatibles avec son absence. Ce sont des résultats de sondes dans ces réseaux, pas un examen exhaustif des 2 900 systèmes, de leurs résolveurs ou de leurs abonnés.

Ces mesures partielles restent utiles si chacune est rattachée à sa question. RFC 8145 montre ce que déclarent les résolveurs qui signalent leur état vers la racine ; RFC 8509 teste le comportement de chemins compatibles derrière des terminaux ; RIPE Atlas apporte des points de mesure distincts. Aucune ne fournit à elle seule un dénominateur complet et pondéré par les utilisateurs pour l’ensemble de l’Internet.

Une liste de suivi n’est pas un verdict

La partie la plus actionnable du rapport n’est pas le pourcentage global. Le tableau 3 recense 50 réseaux affichant les taux d’acceptation observés les plus faibles la semaine précédente, après exclusion des réseaux ayant moins de 1 000 tests où le mécanisme sentinelle était pris en charge. Ce filtre rend les lignes plus utiles qu’une observation isolée ; il ne les transforme pas en audits de préparation.

Parmi les réseaux d’Asie-Pacifique figurent National Telecom en Thaïlande et Teletalk au Bangladesh. APNIC rapporte respectivement 48,4 % sur 1 355 tests compatibles avec le mécanisme et 48,2 % sur 2 046. Ces chiffres signalent des cohortes où un contrôle complémentaire pourrait être utile. Ils ne prouvent pas que tous les résolveurs de ces opérateurs ont le même état, que chaque réponse équivaut à une personne distincte ou qu’une proportion identique de clients perdra l’accès.

APNIC invite les réseaux listés à tester leur propre chemin, notamment avec le site de vérification exploité par Cloudflare, puis à examiner leurs paramètres DNS. C’est le bon usage du tableau : une piste pour l’opérateur, pas un jugement externe. Un fournisseur peut exploiter plusieurs services récursifs, transférer une partie du trafic ou dépendre de clés gérées par un éditeur. Le tableau public ne permet pas d’arbitrer ces configurations.

Le calendrier distingue trois transitions

Le calendrier actuel de l’IANA indique que KSK-2024 est entrée dans la racine le 11 janvier 2025. Les résolveurs suivant RFC 5011 devaient commencer à lui faire confiance un mois plus tard. Le 11 octobre 2026, KSK-2024 doit commencer à signer la racine et KSK-2017 doit cesser de signer. La révocation de l’ancienne clé est prévue le 11 janvier 2027, puis son retrait le 22 mars.

Ces dates correspondent à des états différents. « La nouvelle clé signe » ne signifie pas « l’ancienne clé est révoquée », et la révocation ne signifie pas qu’elle a déjà été retirée de la zone. La période d’attente de RFC 5011 permet à un résolveur d’observer puis de valider une clé successeur avant de l’accepter automatiquement. Mais l’existence du protocole ne prouve pas qu’une installation donnée l’a activé, conserve un état inscriptible ou a reçu les observations nécessaires.

Les rôles sont eux aussi distincts. L’IANA publie les ancres de confiance et les dates ; ICANN/PTI opère le processus KSK ; Verisign assure notamment la maintenance de la zone racine et un point d’observation sur les serveurs racine ; APNIC publie ses analyses de mesure. Chaque opérateur de réseau reste responsable des résolveurs récursifs utilisés par ses clients. APNIC apporte des éléments, mais ne contrôle pas la clé racine et ne décide pas du maintien du calendrier.

Pour un opérateur, le contrôle immédiat est local : vérifier que le résolveur déployé fait confiance à la bonne clé successeur, confirmer que les mises à jour automatiques ou la procédure manuelle approuvée fonctionnent réellement, puis tester les chemins utilisés en production. L’IANA publie les fichiers d’ancres ; les éditeurs documentent leurs propres procédures. Une mesure publique peut indiquer où regarder, mais elle ne réalise pas ce contrôle pour une organisation.

Au 9 octobre, les éléments disponibles soutiennent une conclusion limitée. La clé successeur est publiée depuis plus d’un an, une grande part des signaux et chemins testés l’indique, et APNIC a repéré des réseaux où une vérification ciblée pourrait servir. Les descriptions de 90 %, de plus de 95 % et de 70 % ne forment pas un score unique de préparation. Le 11 octobre, la question opérationnelle sera de savoir si un chemin validateur donné accepte la nouvelle racine signée, et non lequel de ces pourcentages fera le titre.

Sources

rapport APNIC du 9 octobre ; calendrier des ancres et rotations de l’IANA ; RFC 8145 ; RFC 8509 ; RFC 5011 ; mise à jour Verisign du 28 juillet ; FAQ opérateur ICANN 2026 ; test de résolveur Cloudflare.