Pendant deux décennies, l’oracle des routes a vécu sans tests. RIPE NCC vient de lui en donner.

Résumé

• RIPE NCC indique que son nouveau service RISwhois-rs apporte une suite de tests à un outil de recherche de routes qui n’en avait jamais eu, et fait passer l’actualisation des données de huit heures à une heure.
• Le service répond toujours à une question précise : quels préfixes et AS d’origine les collecteurs RIPE RIS ont-ils observés, à quels endroits et à quelle heure ? La liste des tests et le calendrier de migration restent à publier.

Un accent ancien, une nouvelle mécanique

whois -h riswhois.ripe.net 193.0.0.1 n’a rien d’un geste de démonstration. C’est une commande que l’on lance quand on veut une réponse dans le terminal avant de chercher quel tableau de bord ouvre la bonne porte. Depuis 2003, RISwhois donne un accès rapide aux données BGP recueillies par les collecteurs de routes de RIPE. Sa sortie reprend le format RPSL, déjà lisible par quantité d’outils et de spécialistes du routage.

L’interface vient de changer de moteur. Le 26 octobre, pendant RIPE 93, Sam van Kampen, développeur chez RIPE NCC, a présenté RISwhois-rs, un successeur construit ces derniers mois. Le compte rendu officiel de la réunion dit que l’ancien service ne disposait d’aucune suite de tests, ce qui freinait son évolution. L’équipe en a ajouté une. Les données peuvent désormais être actualisées toutes les heures, contre une fois toutes les huit heures auparavant.

La petite ironie du lancement mérite sa place : le premier service Rust de production de RIPE NCC est un outil qui parle WHOIS. Le protocole a l’âge des serveurs Unix qu’on ne redémarre qu’en dernier recours ; son moteur, lui, vient de changer de génération. Les personnes qui le maintiennent disposent enfin de vérifications répétables pour faire évoluer le code.

Ce que la réponse raconte

RISwhois interroge les observations de routage. Selon la requête — adresse IP, préfixe ou ASN — il peut renvoyer les préfixes correspondants, les AS d’origine, les collecteurs où la route a été vue, les horodatages de mise à jour et le nombre de pairs RIS qui l’ont observée. L’option -R peut ajouter des données de validation d’origine RPKI. Certains outils de traceroute savent aussi utiliser un serveur WHOIS pour associer un ASN à chaque saut.

Le format fait partie du service. Un opérateur n’a pas à apprendre une nouvelle interface web pour vérifier si RIS a vu une annonce. Un client en ligne de commande envoie sa requête sur le port 43 et reçoit une réponse structurée proche de RPSL. Cette compatibilité transforme un jeu de données en instrument opérationnel : un script, un technicien ou un outil de diagnostic peuvent employer la même entrée.

Le choix remonte au lancement. En novembre 2003, RIPE NCC décrivait dix collecteurs et plus de 200 pairs IPv4 et IPv6. RISwhois combinait leurs instantanés de tables de routage afin d’indiquer où apparaissait un préfixe et quel AS l’originait. L’idée était de rendre consultable la vue des collecteurs dans un format que les outils existants savaient déjà lire.

Cette fonction garde une portée précise. Une réponse RISwhois rapporte ce que les collecteurs participants ont reçu dans leurs tables observées. Elle ne déroule pas la décision locale de chaque routeur ni le chemin emprunté par chaque paquet. Sa valeur vient justement de cette observation externe des annonces. La bonne question est concrète : qu’a vu cette collecte, depuis quel point et à quelle heure ?

Huit heures laissent le temps à une route de changer trois fois de coiffure

L’ancien calendrier faisait de RISwhois un service de photographie périodique : les données revenaient à intervalles de huit heures. Une actualisation horaire réduit cet intervalle. Pendant un changement de routage, un opérateur peut relancer la requête sans attendre la majeure partie d’une journée de travail.

C’est utile en exploitation. On vérifie plus tôt si une nouvelle annonce a atteint les collecteurs concernés. Une équipe support peut rapprocher l’observation RIS d’un résultat RPKI plus récent. Une sonde programmée peut travailler avec une horloge de données moins lente. L’intérêt n’est pas spectaculaire ; il se mesure en appels répétés qui cessent d’attendre huit heures.

RISwhois actualise son instantané chaque heure. RIS Live suit séparément les messages BGP quasi en temps réel. Le premier interroge les données collectées ; le second suit leur arrivée. Deux services, deux horloges : le cycle publié passe de huit heures à une.

Les fichiers téléchargeables dump et dump6 forment encore une autre surface. La documentation actuelle indique qu’ils sont générés à la demande et correspondent aux commandes du même nom. L’heure de mise à jour du service et celle de génération d’un fichier sont deux données distinctes ; chacune mérite son horodatage.

Une suite de tests change le prix d’une modification

« Il n’y avait pas de suite de tests » tient en une ligne. Pour les mainteneurs, cette ligne pèse sur chaque modification. RISwhois accepte plusieurs formes de requête, émet une réponse structurée, conserve des options de compatibilité et peut inclure des champs RPKI. Chacun de ces comportements est un endroit où une évolution peut casser un client.

Une suite de tests donne aux mainteneurs un endroit où décrire les comportements à préserver et les vérifier après chaque changement. Pour un service en ligne de commande, les cas utiles couvriraient par exemple les recherches par adresse et préfixe, les correspondances exactes ou plus spécifiques, IPv4 et IPv6, les connexions persistantes, les horodatages, les compteurs de pairs, les champs RPKI et les requêtes mal formées. Le compte rendu officiel ne publie pas cette liste. Les lecteurs ne peuvent donc pas encore voir quelle partie de l’interface les tests protègent.

Rust complète ce récit de maintenance. RIPE NCC présente RISwhois-rs comme son premier service Rust de production et dit que le langage facilite une mise en œuvre soignée. Le rapport cite la vitesse, la maintenabilité et l’extensibilité comme objectifs. Il ne publie ni mesure de latence, ni dépôt, ni résultat de tests.

La prochaine note de version doit montrer le travail

RISwhois tient depuis deux décennies une promesse discrète : poser la question dans une langue ancienne et obtenir une vue concise des routes observées. RISwhois-rs garde cette entrée familière tout en apportant une nouvelle implémentation et un délai d’actualisation plus court. C’est une mise à niveau logique pour interroger un système de mesure.

La prochaine publication utile donnerait la date de bascule en production, préciserait si les clients doivent changer, énumérerait les requêtes et sorties couvertes par les tests, puis comparerait les temps de réponse mesurés. Une note de compatibilité versionnée permettrait aux opérateurs de contrôler leurs scripts avant la disparition de l’ancien service. Voilà des faits de livraison qui transforment « nous l’avons réécrit » en « voici ce qui a changé et comment le vérifier ».

Sources premières : annonce de lancement de RISwhois par RIPE NCC, 2003 · documentation RISwhois · session de Sam van Kampen à RIPE 93 · compte rendu RIPE 93, 26 octobre 2026.