Résumé

  • Du 22 au 26 janvier 2026, quelque 2 000 sondes RIPE Atlas ont connu des délais d’attente en IPv4 vers L-Root, selon la présentation RootViz donnée à RIPE 93.
  • L’examen de deux fenêtres de dix minutes a isolé 1 773 sondes touchées seulement pendant l’événement ; des réseaux tiers continuaient pourtant à joindre les sites anycast concernés. Les chercheurs situent le problème sur le trajet réseau.

Le témoin lumineux portait la lettre L. La facture de réparation demandait une enquête autrement plus longue. Dans sa présentation originale à RIPE 93, Giovane Moura revient sur quatre jours de délais d’attente vers le serveur racine exploité par ICANN en janvier.

L’équipe a vu monter les échecs de mesure IPv4 le 22 janvier, puis retomber la courbe le 26. Près de 2 000 sondes ont été concernées durant cette période. Les observations IPv6 et celles des autres identités racines n’ont pas suivi la même pente. Une comparaison particulièrement nette confronte 04 h 00–04 h 10 à 13 h 00–13 h 10 UTC, le 22 janvier : 1 773 sondes qui répondaient dans la première tranche expirent dans la seconde. Le compteur décrit des lieux de mesure ; il ne chiffre pas des usagers privés de DNS.

La nouveauté de RootViz tient au champ de vision. Le projet reprend les mesures des treize identités racines effectuées par RIPE Atlas, vérifie l’état des piles réseau et l’identifiant des serveurs, puis regroupe les sondes en délai d’attente par tranches de trente minutes. Dans la comparaison datée du 6 mai, les auteurs comptent 14 528 sondes contre 999 ancres DNSMON, et 180 pays contre 109. Le catalogue de RIPE Atlas rattache bien la mesure 10308 aux requêtes IPv4 UDP vers L-Root. Un filet plus large attrape davantage de signaux. Pour savoir qui répare, il faut encore suivre le fil.

Les chercheurs ont donc recherché les sites anycast que joignaient les sondes avant l’événement. Ces sites restaient accessibles depuis d’autres réseaux. Les vérifications de chemin et de routage ont conduit à un problème dans le réseau intermédiaire. La présentation ne désigne pas de responsable de transit unique pour cet épisode. ICANN confirme être l’opérateur de L-Root ; c’est à son nom que l’alerte arrive naturellement, alors que chaque tronçon du trajet relève de décisions distinctes.

La leçon de gouvernance est pratique : à qui passe-t-on le dossier quand une sonde cesse de joindre une identité racine ? RootViz a repéré la hausse ; localiser les sondes, les sites, l’état BGP et le problème de transport a demandé des heures de travail manuel. Un compte rendu utile afficherait ces preuves côte à côte avant d’attribuer une faute. L’alarme ouvre l’enquête ; elle ne la clôt pas.

Documents originaux : présentation RIPE 93, mesures intégrées RIPE Atlas, ICANN et le système racine.