Résumé

  • RIPE NCC a publié le 13 août 2026 à 15:03 CEST le postmortem de l’incident NRTM et fichiers split.
  • Selon le rapport, un objet RPSL invalide a arrêté le flux de miroir et désynchronisé les clients à partir de cet objet.
  • Des changements de traitement et de surveillance sont annoncés, avec une livraison prévue dans Whois 1.124 le 27 août.

Le défaut n’était pas seulement dans les données

RIPE NCC situe l’incident du service de miroir NRTM entre environ 00:06 UTC le 2 août et 12:30 UTC le 4 août. Le rapport explique qu’un objet RPSL invalide a été enregistré dans la RIPE Database. Lorsque le service NRTM a atteint cet objet, il a cessé de fonctionner; les clients se sont alors trouvés désynchronisés à partir de ce point.

Cette séquence compte parce qu’elle associe une entrée de données à la façon dont le service traite l’exception. La page d’incident rappelle aussi que le provisionnement de DNS inverse dépend de NRTM : pendant l’investigation, les mises à jour d’objets domain n’apparaissaient pas dans le DNS mondial. RIPE NCC a ensuite indiqué que les mises à jour en attente avaient été traitées et publiées. Rien dans la source ne permet cependant d’étendre cette affirmation à chaque miroir ou à chaque consommateur de données.

Écrire correctement puis laisser passer avec alerte

Le postmortem remonte la création de l’objet invalide à une évolution de Whois 1.122, introduite en avril. Des retours à la ligne supplémentaires dans les attributs descr: et remarks: ont été admis par inadvertance. RIPE NCC dit avoir modifié la substitution des points de code UTF-8 afin de ne plus écrire ces sauts de ligne.

Le second changement porte sur le lecteur du flux. Auparavant, le serveur NRTM ne sautait pas l’objet RPSL invalide et échouait avec une erreur interne. La nouvelle conduite annoncée consiste à ignorer cet objet, à journaliser l’erreur et à permettre à l’équipe base de données de le corriger pour qu’il apparaisse plus tard dans le flux. RIPE NCC présente les deux corrections comme prévues pour Whois 1.124, attendu le jeudi 27 août : ce calendrier n’atteste pas encore leur mise en production.

Vérifier une plage récente plutôt qu’une simple présence

RIPE NCC indique enfin que sa surveillance demandera désormais une plage récente de mises à jour NRTM et en validera la réponse. Cette précision est plus utile qu’un simple contrôle de disponibilité : un service peut répondre sans que la continuité des mises à jour soit démontrée.

Pour les équipes qui consomment ces données, l’enseignement est borné mais concret. Il faut distinguer l’accessibilité d’un endpoint de la progression vérifiable du flux, et conserver un chemin de correction pour les données rejetées. Le rapport ne fournit ni inventaire des clients affectés ni mesure indépendante de récupération; il établit la logique des changements annoncés.

Sources