Résumé
- Une observation effectuée le 13 septembre montre que le glue IPv6 de
.psdans la racine correspond à présent à l’adresse actuelle du serveur RIPE NCC ; les trois autres écarts signalés en août subsistent. - RIPE NCC avait expliqué que ses demandes auprès de l’IANA ne pouvaient aboutir sans l’accord des contacts des ccTLD concernés. Le résultat divergent correspond donc à quatre procédures d’autorisation, pas à un chantier unique.
- Rien ne démontre une panne. Chaque délégation disposait, selon RIPE NCC, d’autres chemins IPv6 et de plusieurs glues IPv4. Ce qui manque est un reçu public, sobre et distinct pour chaque dossier.
Le changement le plus instructif tient dans la disparition d’une ligne. En août, une liste publique comptait quatre adresses IPv6 anciennes dans la racine. En septembre, une nouvelle mesure n’en retrouve plus que trois. Le quatrième cas n’a pas été « presque terminé » avec les autres : il a connu un résultat différent.
Le 15 août, Patrik Wallstrom avait signalé sur la liste du groupe de travail DNS de RIPE les glues encore associés à ne.cctld.authdns.ripe.net, ps.cctld.authdns.ripe.net, sd.cctld.authdns.ripe.net et tj.cctld.authdns.ripe.net. Sept mois plus tôt, RIPE NCC annonçait la fin du renumérotage IPv6 de son service AuthDNS, le retrait complet de l’ancien /48 et l’achèvement de l’essentiel du nettoyage.
La réponse de RIPE NCC, le 20 août, a déplacé la question du réseau vers l’autorité. L’organisation avait tenté de joindre les parties concernées par courrier électronique, téléphone et relais régionaux, puis ouvert des demandes auprès de l’IANA. Mais l’IANA ne pouvait les traiter sans l’accord des contacts des ccTLD. Ce sont les gestionnaires de TLD qui maintiennent les données de leur délégation dans la zone racine.
Il serait tentant de réduire cela à quatre champs mal synchronisés. Ce serait manquer le dispositif de sécurité : l’exploitant d’un serveur sait que son adresse a changé, mais il ne peut pas ordonner seul la modification d’une délégation qui appartient à un autre gestionnaire.
.ps a convergé, les trois autres pas encore
Le relevé gelé à 17 h 14 UTC le 12 septembre — soit le 13 septembre en Asie orientale — a interrogé a.root-servers.net et b.root-servers.net, puis comparé leurs referrals aux réponses de 1.1.1.1 et 8.8.8.8 pour les noms de serveurs.
Pour .ps, les deux serveurs racine ont livré 2a13:27c0:30::105. Les deux résolveurs ont donné la même adresse AAAA pour ps.cctld.authdns.ripe.net. La page de délégation de l’IANA affiche elle aussi cette valeur et indique une mise à jour de page au 8 septembre.
Pour .ne, la racine présentait encore 2001:67c:e0::101, contre 2a13:27c0:30::101 dans la réponse au nom. Les couples correspondants étaient 2001:67c:e0::109 et 2a13:27c0:30::109 pour .sd, puis 2001:67c:e0::117 et 2a13:27c0:30::117 pour .tj. Dans les trois cas, les adresses IPv4 coïncidaient : 193.0.9.101, .109 et .117.
Cette mesure permet d’affirmer une chose et oblige à en taire plusieurs. Le nombre d’écarts est passé de quatre à trois. Elle ne dit ni qui a demandé ou approuvé la modification de .ps, ni quand la racine a commencé à la diffuser. Les dates globales inscrites sur les pages de l’IANA ne précisent pas le champ modifié.
Un chemin de secours n’efface pas l’écart
RIPE NCC a également précisé que chaque délégation possédait au moins un autre glue IPv6 fonctionnel et plusieurs glues IPv4. Les résolveurs pouvaient donc suivre la délégation et résoudre les noms. Ce fait interdit de transformer mécaniquement un glue ancien en récit de panne.
La présente recherche n’a envoyé aucun paquet vers les anciennes adresses. Elle n’a mesuré ni leur joignabilité, ni un éventuel délai de nouvelle tentative, ni un effet pour l’utilisateur. Elle n’établit pas de délégation boiteuse, d’échec DNSSEC, de panne de résolveur ou de perte du service faisant autorité. Les chemins alternatifs expliquent la continuité ; ils ne garantissent pas que tout résolveur a suivi le même parcours sans latence.
Il faut tenir les deux idées ensemble. Une référence vers un préfixe retiré mérite d’être corrigée. Mais exiger l’accord du gestionnaire du ccTLD protège la racine contre une instruction non autorisée. La qualité du contrôle ne se mesure donc pas à la vitesse d’un balayage collectif, mais à la convergence justifiée de chaque dossier.
Les clôtures de 2025 ne sont pas un tableau de bord de 2026
L’audit des opérations racine de l’IANA pour juillet 2025 mentionne, pour les quatre noms, des demandes de changement de serveur marquées Administratively Closed le 18 juillet 2025. Le tableau public ne donne pas le motif propre à chaque clôture. Ces entrées historiques ne décrivent pas l’état des démarches plus tardives rapportées par RIPE NCC et n’expliquent pas l’alignement récent de .ps.
Les fragments publics répondent chacun à une question différente. L’audit dit qu’une ancienne demande s’est terminée. La fiche de délégation montre les données publiées. Une requête DNS saisit une réponse à un instant donné. Il manque le lien entre identité du dossier, autorisation, contrôle technique, décision finale et observation de la racine.
Publier quatre reçus, pas une barre de progression
Un reçu respectueux de la confidentialité pourrait indiquer le TLD, le nom du serveur, l’ancienne adresse, l’adresse demandée, le rôle du demandeur et un identifiant public non sensible. Il préciserait l’état et la date de l’autorisation du gestionnaire, le résultat du contrôle technique, la décision — mise en œuvre, retrait, clôture ou remplacement — ainsi qu’une catégorie de motif.
Il lui faut enfin une heure d’observation ou un numéro de série de la zone racine, le glue effectivement servi, l’action suivante et la référence à toute demande qui le remplace. Aucun nom de personne ni échange privé n’est nécessaire. Le bénéfice est de distinguer une attente d’accord d’un rejet technique ou d’un abandon.
Le compte rendu du groupe DNS à RIPE 91 présentait le renumérotage comme une amélioration opérationnelle et annonçait la capture des requêtes encore envoyées aux anciennes adresses après leur arrêt. Ces traces disent où l’ancien chemin reste sollicité. Le reçu dit qui peut autoriser sa disparition. Le passage de quatre à trois est alors un événement documenté, non une énigme dans une liste.
Sources
- Groupe de travail DNS de RIPE : discussion sur les glues IPv6 obsolètes et réponse de RIPE NCC
- Groupe de travail DNS de RIPE : fin du renumérotage IPv6 d’AuthDNS
- IANA : gestion de la zone racine
- IANA : audit des opérations racine, juillet 2025
- IANA : fiche de délégation de .ne
- IANA : fiche de délégation de .ps
- IANA : fiche de délégation de .sd
- IANA : fiche de délégation de .tj
- Compte rendu du groupe DNS à RIPE 91
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
