Résumé

  • KSK-2024 a commencé à signer la zone racine du DNS à la date prévue du 11 octobre 2026. ICANN indique n’avoir observé aucun signe de perturbation opérationnelle généralisée.
  • Cet état public confirme le basculement dans la zone racine, pas l’adoption du nouveau point de confiance par chaque résolveur ni l’absence de toute panne locale. KSK-2017 reste un point de confiance valide jusqu’aux étapes ultérieures de révocation et de retrait.

Un basculement réussi peut désigner plusieurs choses

La page d’ICANN consacrée au roulement fixe un fait précis : à 14 h UTC le 11 octobre, KSK-2024 a commencé à signer la zone racine. ICANN ajoute qu’aucun signe de perturbation généralisée n’a été observé et que la surveillance se poursuit. IANA indique également que la nouvelle clé est active et que KSK-2017 ne signe plus. Ces faits sont utiles à condition de ne pas leur faire dire davantage.

Le changement de signature à la racine ne signifie pas que chaque résolveur récursif validant a accepté la clé suivante. La zone racine publie des données DNS signées ; les résolveurs récursifs les valident pour leurs clients. Pour construire la chaîne de validation, un résolveur a besoin d’un point de confiance local. S’il ne dispose pas de KSK-2024 lorsqu’il doit vérifier le nouvel état de signature, la validation DNSSEC peut échouer sur ce résolveur. Les clients qui l’utilisent peuvent être touchés sans que la racine ni l’ensemble du DNS soit indisponible.

Il faut donc séparer au moins quatre niveaux de preuve : la publication et la signature de la zone racine ; la clé approuvée par chaque résolveur ; le comportement des logiciels qui mettent cette clé en place ; enfin, le résultat de résolution vu par les utilisateurs. Un relevé à un niveau ne remplace pas les reçus des autres.

Le long délai de préparation répond à l’autonomie des résolveurs

IANA a publié KSK-2024 bien avant son activation. La clé a été introduite dans la zone racine le 11 janvier 2025 ; les résolveurs conformes au mécanisme RFC 5011 devaient commencer à lui faire confiance le 10 février 2025. Cette période d’environ deux ans permettait aux résolveurs compatibles d’apprendre la clé pendant que l’ancienne signait encore la zone. En juillet, le guide d’ICANN indiquait que plus de 95 % des résolveurs déclarants avaient reconnu ou adopté KSK-2024. Le chiffre renseigne sur les déclarants avant la date prévue ; il ne constitue ni un recensement exhaustif ni une mesure de résultat après le basculement.

RFC 5011 distingue la publication de l’acceptation. Le résolveur automatique observe la nouvelle clé dans un ensemble DNSKEY validé, respecte une période de maintien, puis vérifie après cette période qu’un nouvel ensemble validé contient encore la clé avant de l’accepter comme point de confiance. La période minimale est de 30 jours, sous réserve de la règle liée au TTL initial. Chaque résolveur établit cet état à partir des données qu’il voit et conserve localement. Un calendrier central donne du temps pour migrer ; il ne certifie pas les fichiers locaux, les paramètres logiciels ou la validation de toute une flotte.

Le précédent de 2018 montre pourquoi cette limite compte. Selon le bilan d’ICANN, la première date avait été reportée après l’apparition tardive de données signalant que de nombreux résolveurs d’opérateurs et de FAI n’étaient pas prêts. Après le basculement, le volume de requêtes DNSKEY indiquait encore des résolveurs non préparés, sans que le rapport relève de panne importante ; l’impact visible pour les utilisateurs était faible. L’opérateur de la racine ne pouvait ni mesurer ni contrôler chaque résolveur, géré par son propre exploitant. La formulation prudente de 2026 reflète cette réalité.

Octobre marque le basculement, pas la fin du cycle

La séquence n’est pas achevée. D’après le calendrier actuel d’IANA, KSK-2017 a cessé de signer le 11 octobre 2026, mais demeure un point de confiance valide. Sa révocation, par publication du bit REVOKE, est prévue le 11 janvier 2027 ; son retrait de la zone racine, le 22 mars. Ce sont des transitions distinctes, avec leurs propres effets locaux. Le changement de signature d’octobre ne signifie pas que l’ancienne clé a déjà été supprimée ou que toute confiance en elle a disparu.

Les mécanismes varient : mise à jour automatique, paquet du fournisseur, fichier d’ancre géré manuellement, micrologiciel ou résolveur hébergé. Une même organisation peut cumuler ces voies. La disponibilité d’un paquet ne prouve pas son installation ; la présence d’une clé ne garantit pas la persistance de la mise à jour ; une requête réussie depuis un point de test ne représente pas tous les chemins clients. Ces états doivent être vérifiés séparément.

ICANN demande aux opérateurs de vérifier la présence de KSK-2024, identifiée par le tag 38696, et de ne pas présumer que la mise à jour automatique a réussi. IANA désigne le fichier XML signé des ancres comme source normative des paramètres et renvoie aux consignes des fournisseurs. L’objectif de contrôle local est donc clair, même si les preuves sur l’ensemble des résolveurs restent distribuées.

Ce que le dossier public établit

Les sources publiques établissent que la nouvelle clé a pris la relève à la date prévue, qu’ICANN n’avait pas observé de perturbation généralisée lors de sa mise à jour, et que révocation et retrait de l’ancienne clé sont à venir. Elles ne fournissent ni inventaire par résolveur, ni dénominateur après basculement, ni taux d’adoption général, ni nombre d’utilisateurs touchés. L’absence de panne publiée ne prouve pas qu’aucun résolveur ni client n’a rencontré de problème.

Il faut lire l’état public à son échelle exacte. L’opérateur de la racine rapporte la signature et les signaux observés ; l’opérateur récursif connaît son propre point de confiance et sa validation ; le fournisseur peut expliquer la diffusion des paquets ; le prestataire DNS voit ses clients. Aucun ne possède à lui seul une vue exhaustive.

Après un roulement planifié, la question utile n’est donc pas seulement de savoir si la date a été tenue. Il faut établir la chaîne de preuve jusqu’aux systèmes qui dépendent de la clé, puis vérifier que les prochaines étapes préservent une voie de récupération. Le bilan public de 2026 est encourageant mais circonscrit : la racine a changé à l’heure et aucune perturbation généralisée n’avait été observée. Le reste doit être vérifié au niveau des résolveurs et des services, tandis que les échéances de janvier et mars 2027 restent devant nous.