Résumé

  • Le résultat d’environ 70 % d’APNIC est conditionné par les tests qui ont clairement émis le signal sentinelle RFC 8509 ; le chiffre d’environ 90 % de Verisign concerne les résolveurs déclarant leur état au titre de la RFC 8145. Ce ne sont pas deux estimations de la même population.
  • La racine a commencé à signer avec KSK-2024 le 11 octobre 2026. Les informations publiques confirment le changement et l’absence de perturbation généralisée observée, mais elles ne dénombrent ni tous les résolveurs, ni les personnes uniques, ni les échecs isolés.

Un pourcentage sans dénominateur trompe

La lecture la plus tentante des chiffres du changement de clé est aussi la moins défendable : si environ 70 % du groupe mesuré faisait confiance à la nouvelle clé, les 30 % restants seraient peut-être des utilisateurs exposés. Cette conclusion change le dénominateur sans preuve. APNIC Labs n’a pas prétendu avoir compté tous les résolveurs ou toutes les personnes. Son résultat décrit des tests capables de manifester une caractéristique de mesure donnée.

APNIC indique que son système de tests fondé sur la publicité produit environ 16 millions de tests par jour. Environ six millions de résultats quotidiens indiquent un résolveur validant DNSSEC ; près de 1,8 million présentent clairement le signal sentinelle RFC 8509. Le taux d’environ 70 % est calculé parmi les tests qui semblent prendre en charge ce signal et déclarent KSK-2024 comme ancre de confiance. Un test est une observation, pas la preuve d’un utilisateur unique.

Des événements répétés peuvent provenir des mêmes personnes, du même réseau ou du même résolveur ; la méthode publiée ne les transforme pas en recensement pondéré de la population.

Cela reste une information utile. Dans le sous-ensemble mesurable capable de répondre au test, la nouvelle ancre n’était pas universellement présente au moment des observations d’APNIC. Le résultat peut révéler des tendances et orienter les vérifications. Sa valeur dépend toutefois du maintien de cette condition à côté du chiffre.

Verisign a observé un autre signal

Le chiffre d’environ 90 % résumé par APNIC provient des rapports RFC 8145 de Verisign. Un résolveur compatible peut signaler au système des serveurs racine les étiquettes de clés qu’il reconnaît comme ancres de confiance. Le point d’observation diffère d’une requête sentinelle RFC 8509 émise du côté de l’utilisateur final. L’échantillon comprend les résolveurs qui prennent en charge le mécanisme et dont les rapports sont observables ; il ne comprend pas par définition tous les résolveurs récursifs.

Un résolveur déclarant ne représente pas une personne. Il peut desservir un foyer, une entreprise, un fournisseur d’accès ou plusieurs réseaux en aval. Le rapport disponible ne donne pas le nombre d’utilisateurs derrière chaque résolveur, ce qui permettrait de pondérer les résultats par population. L’écart entre 70 % et 90 % ne démontre donc ni contradiction, ni évolution entre échantillons équivalents, ni progression globale de dix points. Les protocoles, les critères d’inclusion, les périodes de collecte et les chemins réseau diffèrent.

Une petite mesure RIPE Atlas apporte un troisième contrôle, mais ne départage pas les deux taux. Le 5 octobre, des sondes réparties dans 2 900 systèmes autonomes comprenaient 1 230 cas compatibles avec le chargement de la nouvelle clé et 47 compatibles avec son absence. Ce jeu limité n’était pas pondéré par le nombre d’utilisateurs. La liste d’APNIC des réseaux affichant de faibles taux d’acceptation impose également un minimum de tests sentinelles pour rendre les comparaisons plus lisibles ; ce seuil ne prouve pas une panne à l’échelle du réseau.

La signature racine ne révèle pas l’ancre locale

IANA classe KSK-2024, étiquette 38696, comme active et signant la racine depuis le 11 octobre. KSK-2017, étiquette 20326, est encore en phase de post-publication et demeure une ancre valide. Sa révocation est prévue le 11 janvier 2027 et sa suppression le 22 mars. Ces états opérationnels sont distincts : la nouvelle clé peut signer alors qu’un validateur conserve l’ancienne comme ancre valide.

Le statut publié par ICANN indique que la nouvelle clé a commencé à signer à 14 h UTC le 11 octobre et qu’aucun signe de perturbation opérationnelle généralisée n’avait été observé dans sa mise à jour ; la surveillance devait se poursuivre. Cette information décrit le tableau opérationnel observé, pas l’état de chaque validateur local. Elle ne prouve pas non plus qu’aucun incident isolé ne s’est produit. À l’inverse, un test qui ne montre pas la nouvelle clé ne prouve pas à lui seul qu’une requête DNS a échoué.

Le mécanisme de panne est conditionnel. Un résolveur qui valide DNSSEC et ne dispose pas d’une chaîne de confiance utilisable pour la racine peut rejeter des données signées. Un résolveur qui ne valide pas DNSSEC ne tombe pas en panne par cette voie précise. Même pour un validateur, le résultat dépend de l’état local des ancres, de la configuration et du chemin de requête. La signature de la racine indique la clé utilisée pour la zone ; elle ne révèle pas l’état de chaque validateur situé en aval.

Ce que les mesures autorisent à conclure

Trois conclusions limitées sont étayées. Premièrement, le changement de signature a eu lieu à la date prévue. Deuxièmement, plusieurs instruments montrent une adoption importante, mais chacun décrit son propre sous-ensemble observable. Troisièmement, le statut postérieur au changement examiné ne signalait pas de perturbation généralisée. Les éléments ne permettent pas d’affirmer que 30 % des utilisateurs étaient exposés, que 10 % de tous les résolveurs n’avaient pas la clé ou que la préparation avait atteint 100 %.

La donnée manquante n’est pas un nouveau pourcentage accrocheur. Il faut relier de façon défendable les observations au nombre et à la répartition des résolveurs validateurs concernés, puis aux utilisateurs et services qu’ils desservent. Cela exige une couverture explicite, la déduplication, des fenêtres temporelles, une pondération et une mesure des résultats après le changement. En attendant, chaque taux doit conserver son dénominateur ; l’état observé de la clé doit rester distinct de l’impact supposé sur les utilisateurs.

Sources