Résumé

  • Le commit Whois 252681a, daté du 10 septembre, fait utiliser au service NRTMv4 un NrtmSourceSlaveDao pour l’inventaire des sources comme pour la validation d’un nom demandé.
  • Le DAO des notifications sait relancer une recherche sur la source maîtresse après un résultat vide côté esclave, mais il n’est appelé qu’après la création de l’objet source par la première lecture.
  • Rien ne prouve un déploiement, un retard de réplication ou une panne. Un reçu d’admission de source suffirait à encadrer la phase rare d’activation sans renoncer aux lectures sur réplique.

Une reprise sur erreur n’est jamais plus large que le point où elle commence. Cette évidence d’architecture est précisément ce que rend visible le commit 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855 du dépôt Whois du RIPE NCC.

Publié le 10 septembre 2026 à 10 h 56 UTC, le changement porte un titre sans emphase : « Use read-only (slave) source DAO in NRTMv4 Service ». Trois fichiers seulement sont concernés. NrtmSourceDao reçoit l’annotation @Primary. Un sous-type de vingt lignes, NrtmSourceSlaveDao, reprend sa logique en lui fournissant nrtmSlaveDataSource. Enfin, NrtmService dépend désormais de ce sous-type.

Il faut commencer par la meilleure justification du changement. Un catalogue de sources est minuscule par rapport au rythme auquel des clients viennent chercher des publications. Ses noms bougent rarement. Servir ces lectures depuis une réplique protège le chemin d’écriture, limite la contention et isole mieux la diffusion publique. À cela s’ajoutent les garanties propres à NRTMv4 : notification signée, empreintes des instantanés et des deltas, identifiant de session, versions ordonnées. Le code contient même déjà une reprise vers la source maîtresse lorsqu’une notification manque sur un contexte esclave.

Le sujet n’est donc ni l’imprudence, ni une prétendue fragilité intrinsèque des répliques. Il tient à l’ordre de deux décisions.

Le catalogue décide avant la notification

Le DAO de base interroge la table source et restitue l’identifiant et le nom de chaque entrée. Sa construction normale emploie nrtmMasterDataSource. Le nouveau DAO hérite exactement de cette méthode, mais transmet le datasource qualifié de réplique. Le service l’utilise à deux endroits.

Sur la page racine, il parcourt getSources() et fabrique un lien vers le fichier de notification de chaque source. Ce qui n’est pas encore visible sur le côté lecture n’est donc pas annoncé sur cette page.

Sur le chemin d’un fichier de notification, la ligne décisive compose deux appels : findLastNotification(getSource(source)). La méthode interne getSource() relit le catalogue, cherche un nom identique et lève une erreur « Invalid source » en l’absence d’entrée. Ce n’est qu’avec l’objet ainsi obtenu que le DAO des notifications peut être invoqué.

L’évaluation des arguments en Java fixe l’ordre. La résolution de la source doit aboutir avant l’appel de findLastNotification. Si la réplique ne présente pas encore la ligne, le code s’arrête à la porte. Le composant qui sait effectuer un repli ne reçoit ni appel ni objet.

Ce composant mérite pourtant d’être crédité. UpdateNotificationFileSourceAwareDao recherche d’abord le dernier contenu de notification. Quand le résultat est vide et que le contexte courant est de type SLAVE, il construit la source maîtresse correspondante, modifie temporairement le contexte, relance la requête puis restaure l’état initial dans un bloc finally. Il protège le cas où la source est connue mais où son dernier contenu n’est pas encore accessible par le premier chemin.

Il ne protège pas le cas précédent, celui où la source n’a pas été reconnue. Dire simplement « il existe un repli vers le maître » efface cette différence. La liste racine n’en bénéficie pas. La route directe en bénéficie pour la charge utile, après avoir franchi l’admission par le catalogue.

Une question d’ouverture, pas de régime permanent

Dans un service établi, l’observation peut n’avoir aucun effet visible. Les quelques lignes du catalogue ont probablement été répliquées bien avant chaque requête. Une fois la source reconnue, la recherche de notification conserve son mécanisme de secours. Le commit public ne contient aucune mesure de décalage, aucun relevé de réponse, aucun client affecté.

La frontière devient pertinente au moment d’introduire une source, de recréer une entrée, de remettre un datasource en service ou de basculer une configuration. La base principale peut alors connaître un nom que le chemin de lecture n’a pas encore observé. Sous cette condition, la page racine ne le proposerait pas et une demande directe serait rejetée avant la reprise de notification. Il s’agit d’une conséquence conditionnelle du code, pas du récit d’un incident.

Le statut de déploiement reste lui aussi inconnu. Un commit dans une branche publique n’est ni un numéro de version, ni une preuve de présence en production. Rien dans le dossier ne permet d’affirmer qu’un point d’accès actuel exécute ces lignes. Les mots « panne », « perte de données » ou « vulnérabilité » dépasseraient donc les faits.

Une réplique assume généralement une convergence asynchrone pour gagner en capacité et en séparation. Ce compromis convient à beaucoup de lectures. La bonne question de gouvernance est de savoir quelles décisions peuvent être prises sur une vue potentiellement décalée. Lire sans cesse un catalogue stable en est une. Modifier l’ensemble des noms que le public peut découvrir et demander en est une autre.

La preuve cryptographique commence après l’admission

La révision 11 du projet NRTMv4, telle que l’indique l’IETF Datatracker lors de la capture, décrit la synchronisation unidirectionnelle de registres de routage Internet via HTTPS. Une publication réunit un fichier Update Notification, un Snapshot actif et, selon les mises à jour, plusieurs Delta Files.

La notification adopte le format JSON Web Signature. Le client connaît son URL, le nom du registre IRR et une clé publique. Il vérifie le nom de source et la signature, puis compare les empreintes SHA-256 des instantanés et deltas téléchargés avec celles de la notification signée. Le session_id donne son domaine aux numéros de version ; s’il change, le client doit repartir du dernier instantané pour éviter un trou silencieux dans l’historique.

Ces règles sont fortes. Elles permettent d’établir l’origine d’une notification, l’intégrité des fichiers et la continuité d’une session. Elles n’attestent pas qu’une ligne de catalogue interne a rejoint la réplique consultée par le serveur avant l’ouverture d’une source. Tant que le serveur refuse le nom, le client ne peut même pas obtenir l’objet qu’il saurait vérifier.

Ce n’est pas une lacune à combler dans le protocole. Exposer la topologie des bases, leurs positions de réplication ou leurs noms internes serait inutile et parfois dangereux. Le contrôle appartient à la procédure de mise en service du producteur.

Un reçu au moment où le nom devient public

Le dispositif minimal serait un reçu d’admission du catalogue de sources. Il peut rester interne. Sa valeur vient du lien entre des étapes qui existent probablement déjà, pas d’une publication de détails d’infrastructure.

Le reçu associerait le nom de la source et la génération du déploiement à l’approbation côté écriture, au chemin de lecture destiné au service et à un horodatage — ou une borne de préparation équivalente — montrant que ce chemin voit l’entrée. Il ajouterait la première récupération réussie d’une notification signée par le chemin de service, le session_id et la version observés, une référence de clé, un contrôle de la liste racine et un contrôle de la route directe. Un responsable, l’heure d’activation, une condition de retour arrière et le lien vers un reçu successeur compléteraient l’ensemble.

Les noms d’hôtes, offsets de réplication, identifiants de lignes et secrets ne sont pas nécessaires. Le fait utile est plus abstrait : la génération destinée au service a observé la source avant que cette source ne soit admise.

La séquence opérationnelle peut rester simple. Créer ou approuver la source sur le chemin d’écriture ; attendre son observation sur le datasource réellement utilisé par NrtmService ; récupérer et valider une première notification signée via ce chemin ; ouvrir ensuite la source. Si le délai maximal est dépassé, l’activation reste en attente ou emprunte une voie temporaire, explicitement autorisée et révocable.

Deux tests séparés éviteraient aussi un faux sentiment de couverture. Le premier mettrait une nouvelle source sur la base maîtresse mais pas encore sur la réplique et vérifierait la politique d’admission choisie. Le second rendrait la source visible tout en retirant la notification côté lecture, afin de confirmer le repli actuel. Même symptôme possible, états de contrôle différents.

Cette approche préserve surtout le bénéfice du commit. Il serait disproportionné de renvoyer chaque lecture de catalogue vers la base principale parce qu’une transition rare exige une preuve. Le contrôle doit s’attacher à l’événement qui modifie l’ensemble admissible, non à chaque consultation de cet ensemble.

Sources