Résumé

  • La configuration NS2 publiée par AFRINIC comporte dix-sept sites : six possèdent une paire complète de mesures « avant/après », tandis que onze n’ont aucun des deux identifiants et sont classés comme en attente de configuration.
  • Les douze mesures DNS reliées sont toutes marquées ponctuelles et arrêtées par RIPE Atlas. Elles peuvent étayer une comparaison historique, mais leur dernier résultat ne constitue pas une observation en temps réel.

Le présent grammatical d’une page n’est pas celui d’une mesure

Le tableau de mesure NS2 d’AFRINIC se présente comme un outil de « Real-time Anycast Node Monitoring ». Il propose un RTT moyen, des écarts avant/après, une vue des sondes et une date de dernière mise à jour. Cette grammaire visuelle est familière : elle suggère un instrument dont l’aiguille bouge avec le réseau.

Les fichiers publics racontent une autre histoire, plus limitée mais parfaitement exploitable. La configuration des nœuds énumère dix-sept sites. Le code de l’application ne déclare un site « Configured » que si les champs beforeMeasurementId et afterMeasurementId sont tous deux renseignés. Si les deux manquent, il affiche « Pending Configuration » puis « No measurements configured ».

Six sites disposent de la paire : KIXP à Nairobi, HIXP à Harare, LSKIX à Lusaka, DoualaIX à Douala, IXPN à Lagos et MIXP à Rose Hill. Onze n’ont aucun identifiant : JINX, s02.iso, CINX, s01.pkl, s02.pkl, DINX, NMBINX, DarIX, UIXP, RINEX et TUNIX. Aucun site n’a seulement la moitié d’une paire. La couverture déclarée par le fichier est donc nette : six comparaisons configurées, onze en attente.

Pour chaque paire, le navigateur appelle l’URL Atlas /measurements/{id}/latest/. Le mot latest désigne le dernier résultat disponible pour cet identifiant. Il ne garantit ni une mesure périodique, ni une exécution en cours, ni une observation récente. Une campagne arrêtée garde un dernier résultat. Le consulter en septembre ne transforme pas son horodatage de décembre ou de février.

La nuance détermine l’usage professionnel de la donnée. Une expérience avant/après répond à une question bornée : qu’ont observé certaines sondes de part et d’autre d’un changement ? Une supervision courante en pose une autre : que voit-on maintenant, depuis quelles perspectives, vers quel nœud, et avec quel âge maximal de donnée ? Les deux produits peuvent partager un graphique. Ils ne peuvent pas partager silencieusement le même statut.

La carte de déploiement, la liste des sites et les mesures comptent trois choses

La page du programme DNS Anycast d’AFRINIC réunit deux familles d’infrastructure. AS37181 est associé aux nœuds CIP de DNS inverse ; AS37177, aux nœuds NS2 qui soutiennent des domaines de premier niveau africains. Le programme demande aux hébergeurs une capacité anycast, de la redondance et un soutien opérationnel permanent.

La carte de distribution s’appuie sur deux inventaires téléchargeables. Le fichier des hôtes CIP contient vingt lignes et celui des hôtes NS2, vingt autres. L’unité est ici l’hôte publié dans l’inventaire de déploiement.

Le script public de la carte confirme que ces deux inventaires alimentent l’affichage.

Le tableau de mesure porte, lui, l’en-tête « NS2 DNS Measurement » et compte des sites. Ses dix-sept libellés ne sont pas quarante hôtes en miniature. Plusieurs hôtes peuvent cohabiter dans une même implantation ; surtout, la surface de mesure est dédiée à NS2, pas à CIP. Il serait donc erroné de calculer quarante moins dix-sept et d’appeler le reste « non mesuré ».

La règle saine consiste à préserver les dénominateurs. L’inventaire dit combien de lignes d’hôtes il publie. La configuration dit combien de sites possèdent deux identifiants expérimentaux. Le fournisseur de mesure dit combien de campagnes et de sondes ont effectivement existé. Une véritable supervision dirait combien de sites sont observés de façon actuelle. Une hausse dans une colonne ne prouve pas une hausse dans les trois autres.

Les douze campagnes ont toutes cessé

Les six paires renvoient aux fiches publiques suivantes :

Site Identifiant « avant » configuré Identifiant « après » configuré Sondes planifiées indiquées par Atlas
KIXP 154055021 154055966 16 / 16
HIXP 142775401 142775907 3 / 3
LSKIX 142730550 142730838 6 / 6
DoualaIX 155156750 155156902 2 / 2
IXPN 143072543 147523251 12 / 10
MIXP 142741062 142740732 8 / 8

Dans les douze fiches, is_oneoff vaut true et le statut est Stopped. La plus ancienne fenêtre commence le 8 décembre 2025 ; la plus récente s’achève le 16 février 2026. La plupart ne durent qu’environ cinq minutes. La référence de l’API RIPE Atlas définit elle-même le caractère ponctuel et l’état arrêté. Il ne s’agit pas d’une qualification éditoriale ajoutée aux données.

Ces campagnes ne sont pas pour autant défectueuses. La paire KIXP, par exemple, vise la même adresse et le même ASN avant et après. Avec un ensemble de sondes comparable, elle peut documenter une variation de RTT autour d’un déploiement. Sa valeur est précisément liée à cette fenêtre. Une expérience correcte en février ne devient pas une mesure courante en septembre simplement parce que son résultat reste accessible.

La taille des cohortes doit également suivre le chiffre affiché. Deux sondes planifiées peuvent répondre à une question locale bien dessinée à Douala. Elles ne représentent pas automatiquement un service anycast continental. Seize sondes à Nairobi offrent davantage de perspectives sans conférer de continuité à une campagne ponctuelle. Localisation des sondes, chemin réseau, cible, requête DNS, adresse IP et identité du nœud répondant sont des éléments du résultat, pas des annexes décoratives.

Deux paires réclament une note d’alignement

La configuration HIXP place la mesure 142775401 dans le champ « avant », alors que sa description Atlas se termine par « After ». La seconde mesure, 142775907, porte une description générique pour le Zimbabwe et vise un autre ASN ainsi qu’une autre adresse IP. Une logique de comparaison peut exister ; la page doit néanmoins dire pourquoi ces cibles forment une paire et quel libellé a été validé.

Pour MIXP, les mots semblent inversés. Le champ « avant » contient 142741062, décrite par Atlas comme « Mauritus - After ». Le champ « après » contient 142740732, dont la description dit « before ». Cela peut être un simple ordre de champs. Cela ne prouve ni panne DNS, ni mauvais déploiement, ni corruption des résultats. Cela prouve seulement que le sens du graphique doit être accompagné d’une correspondance vérifiable.

La prudence va dans les deux sens. Une incohérence de métadonnées ne doit pas être gonflée en incident opérationnel. Mais l’élégance d’un graphique ne doit pas non plus dispenser de vérifier la cible, la cohorte et l’ordre. Une correction durable ajoute une nouvelle correspondance, conserve l’ancienne empreinte et indique sa période de validité ; elle ne réécrit pas silencieusement le passé.

L’anycast rend la perspective indissociable de la mesure

Le RFC 4786, consacré à l’exploitation de services anycast, explique que l’observation varie selon la place du client dans le système de routage. Il recommande des sondes réparties de façon représentative et, lorsque c’est possible, l’enregistrement de l’identité du nœud répondant avec les statistiques de performance et de disponibilité.

Ce texte n’est pas un cahier des charges contraignant pour AFRINIC et son existence ne démontre aucune faute. Il donne toutefois la bonne unité d’analyse. Une mesure anycast est l’association d’une cible, d’une sonde, d’un chemin, d’un nœud répondant et d’un instant. Retirer l’instant transforme l’histoire en présent. Retirer l’identité du nœud expose à attribuer la réponse au mauvais site. Retirer la cohorte permet de présenter un résultat local comme régional.

La responsabilité est elle aussi distribuée. Dans son programme de copies de serveurs racine, distinct du tableau NS2, AFRINIC se décrit comme facilitateur et laisse l’exploitation de la copie à l’opérateur ainsi que le soutien local à l’hébergeur. Le RFC 6304 apporte le contexte opérationnel d’AS112, mais n’attribue pas automatiquement les rôles de chaque nœud CIP ou NS2. La surface de mesure doit donc promettre seulement ce qu’elle observe réellement.

Un reçu par nœud suffit à restaurer la chronologie

La solution n’est pas forcément un nouveau portail. Une fiche courte, attachée à chaque site et à chaque finalité de mesure, rétablirait la chaîne de preuve.

Elle commencerait par l’unité : service NS2 ou CIP, hôte ou site, libellé public et NSID lorsqu’il est observé sans risque. Elle qualifierait ensuite l’état : inventaire de déploiement, expérience préalable, expérience postérieure ou supervision de santé courante. Un champ de finalité empêche le design de promouvoir une archive en outil en direct.

Le contrat de mesure conserverait les deux identifiants, leur ordre avant/après validé, l’ASN et l’IP cibles, la requête DNS, la famille d’adresses, les sondes demandées et planifiées, les heures de début et de fin, ainsi que le mode ponctuel ou périodique. Si cible ou cohorte change entre les deux côtés, le reçu expliquerait la comparabilité ou indiquerait qu’aucune comparaison directe n’est permise.

La fraîcheur aurait deux dates. La dernière récupération par le tableau n’est pas la dernière observation du réseau. Une troisième donnée fixerait l’âge maximal admissible pour un badge de santé courante. Passé ce seuil, l’interface afficherait « historique » ou « trop ancien pour l’état actuel » au lieu de prolonger indéfiniment la couleur du dernier point.

Enfin, la fiche nommerait des rôles, non une topologie sensible : responsable de la définition, responsable de la correspondance entre site et mesure, canal de contestation pour l’hôte ou l’opérateur de ccTLD. Les numéros de série des routeurs et les seuils de capacité resteraient privés. L’empreinte, la période et le motif d’une correction resteraient publics.

On obtiendrait des états modestes mais utiles : déployé sans instrumentation ; paire expérimentale configurée ; expérience terminée ; observation continue active ; observation actuelle périmée ; correspondance en révision. Un programme sain peut comporter simultanément ces états. La précision ne crée pas de panne. Elle évite de baptiser « panne » ce qui n’est qu’une instrumentation inachevée, et « temps réel » ce qui n’est qu’une archive.

Pièces publiques utilisées

Le calcul est reproductible depuis la page du programme, la carte, le tableau NS2, sa configuration, son code client et les inventaires CIP et NS2. Les douze fiches Atlas sont reliées individuellement dans le tableau ; les définitions viennent de la documentation Atlas. Le RFC 4786, le programme racine et le RFC 6304 servent uniquement à borner l’interprétation et les rôles.