Résumé

  • Le répertoire statistique d’ARIN contenait la paire correcte delegated-arin-extended-20260829 et .md5, ainsi que deux chemins supplémentaires : delegated-arin-extended-20231018 et delegated-arin-extended-20231008.md5.
  • L’en-tête du fichier servi par le premier chemin supplémentaire se terminait par 20260829|-0400. Le second contenait exactement le même manifeste que le fichier MD5 correctement nommé et désignait la cible delegated-arin-extended-20260829.
  • Cinq plages de 65 536 octets, réparties dans les deux gros objets, ont produit des empreintes SHA-256 identiques par paire. Ce sondage étaye l’hypothèse d’une copie, sans prouver l’identité intégrale des fichiers ni l’exactitude de chaque enregistrement.
  • La norme publiée par ARIN exige déjà la concordance du nom daté, de l’en-tête et du fichier de contrôle. Il faut vérifier ces trois identités ensemble et conserver la trace de toute correction.

Un manifeste honnête sous une mauvaise étiquette

Le détail le plus instructif se trouve dans le petit fichier de 67 octets. À l’adresse se terminant par 20231008.md5, le contenu capturé indiquait :

6e57e7c85222c5ff9c1549d1ff8ea52c delegated-arin-extended-20260829

Le répertoire public d’ARIN affichait au même moment ce chemin de 2023 avec une date de modification du 29 août 2026. Le manifeste ne prétendait pourtant pas contrôler un fichier du 8 octobre 2023. Il demandait au logiciel de vérifier le fichier correctement nommé pour le 29 août 2026.

C’est un écart important. La vérification MD5 peut réussir si l’outil trouve la cible déclarée et si ses octets correspondent à l’empreinte. Elle ne certifie pas que l’URL par laquelle le manifeste a été obtenu est bien nommée. Elle ne transforme pas non plus 20231008 en date canonique de l’édition.

La paire régulière était bien présente : delegated-arin-extended-20260829 et son fichier .md5. Les chemins persistants latest existaient également. Le problème observé ne porte donc pas sur l’absence de l’édition courante, mais sur deux identités supplémentaires et contradictoires.

Le gros fichier disait lui aussi 2026

L’autre objet supplémentaire portait le nom delegated-arin-extended-20231018. Sa taille annoncée, 12 774 921 octets, était identique à celle du fichier courant correctement nommé. Sa première ligne était :

2.3|arin|1788008421241|202440|19700101|20260829|-0400

La spécification d’échange statistique publiée par ARIN définit cette ligne comme version|registry|serial|records|startdate|enddate|UTCoffset. Le dernier jour représenté dans l’objet était donc le 29 août 2026. Le nom public évoquait le 18 octobre 2023.

Pour aller au-delà de l’en-tête sans prétendre avoir réalisé un audit complet, cinq plages ont été prélevées sur les deux chemins de données : au début, puis à partir des décalages 1 048 576, 4 194 304, 8 388 608 et 12 000 000. Chaque plage comptait 65 536 octets. Dans les cinq cas, les empreintes SHA-256 des plages correspondantes étaient identiques.

Ces résultats rendent plausible une duplication de l’objet courant sous un chemin ancien. Ils ne valent pas empreinte intégrale du fichier supplémentaire. Surtout, ils ne disent rien de la justesse des 202 440 lignes annoncées par l’en-tête. Aucun ASN, bloc IPv4, préfixe IPv6 ou titulaire n’a été vérifié au niveau de l’enregistrement dans cette enquête.

La conclusion doit rester à la hauteur de la preuve : l’identité de publication est incohérente. Il n’existe pas de preuve publique d’une altération du registre.

La norme exige davantage qu’une somme de contrôle

Le texte d’ARIN est utile parce qu’il ne réduit pas la validation à MD5. Il prescrit un nom de la forme delegated-<registry>-yyyymmdd, la date étant celle de la production locale du fichier. Il demande que le contrôle MD5 soit publié « sous un nom correspondant », auquel s’ajoute l’extension .md5. Enfin, sa section de validation mentionne séparément l’en-tête, la comparaison entre le nom et le contenu, et les fichiers de contrôle détachés.

Ces obligations forment une relation, pas trois cases indépendantes. Le chemin indique l’édition recherchée. L’en-tête indique la période et la série que le producteur place dans les octets. Le manifeste lie une empreinte à un nom de cible. Quand les trois concordent, une machine peut citer une édition sans deviner. Quand ils divergent, un contrôle réussi sur les octets ne résout pas la question du classement.

Ce point est particulièrement important pour les statistiques de registres, car les noms datés deviennent souvent des clés de base de données. Un collecteur construit l’URL à partir du calendrier. Un miroir conserve les objets découverts. Un chercheur prend le suffixe yyyymmdd comme date d’observation. La plupart de ces opérations sont raisonnables lorsque le contrat de nommage est respecté.

Dans le cas présent, un collecteur pourrait ranger des octets de 2026 dans une case de 2023. Un outil qui suit le nom inscrit dans le manifeste contrôlerait le fichier 20260829 et pourrait afficher un résultat positif, tandis que le catalogue conserverait encore le chemin 20231008. Ce scénario est techniquement possible ; aucune source ne montre qu’il s’est effectivement produit.

La lecture la plus favorable reste la meilleure base

Rien n’oblige à imaginer une réécriture de l’histoire. Les fichiers corrects étaient accessibles. Les cinq sondages correspondaient. Les deux manifestes complets étaient identiques et pointaient vers la cible actuelle. Les chemins supplémentaires peuvent n’être que des alias involontaires ou des résidus temporaires de publication.

L’archive 2023 d’ARIN conserve par ailleurs des entrées compressées séparées. Cette analyse n’en examine pas le contenu et ne prétend pas qu’un ancien fichier a disparu. Elle ne connaît ni le processus, ni la personne, ni le logiciel ayant créé les chemins supplémentaires.

ARIN a déjà montré qu’une correction de surface est possible. Son avis de 2013 explique que des fichiers alors corrompus ou incomplets avaient été retirés avant la reprise d’une publication correcte. Le cas de 2026 n’est pas assimilé à cet incident : aucune corruption de données n’est établie. L’exemple montre seulement qu’une lignée de correction peut être publique.

Ici, le remède proportionné serait beaucoup plus léger. ARIN peut supprimer les chemins non voulus, ou déclarer explicitement leur relation d’alias s’ils sont intentionnels. Une note brève aiderait les miroirs à comprendre pourquoi leur inventaire diffère. Il n’est pas nécessaire de retirer l’édition correcte ni de présenter l’événement comme une crise du registre.

Faire de l’identité un objet vérifiable

Avant exposition publique, une porte de publication peut assembler un reçu unique. Il contiendrait le chemin canonique, les alias autorisés, les champs analysés de l’en-tête, la longueur, une empreinte forte moderne, le chemin du manifeste, son algorithme, sa cible déclarée et le résultat de la vérification.

Trois règles simples auraient détecté la situation : la date du chemin canonique doit correspondre à enddate ; le nom du manifeste doit prolonger le nom des données ; la cible inscrite dans le manifeste doit être le fichier canonique. Un alias intentionnel peut déroger à la première règle s’il est explicitement relié au reçu canonique. Un nom daté silencieux ne devrait pas le pouvoir.

Le reçu doit aussi être corrigeable sans effacement. Un nouvel état peut référencer l’empreinte du précédent, la date de correction et une catégorie de raison. Les détails internes sensibles ne sont pas nécessaires. La surface publique a seulement besoin de savoir quel objet était canonique et ce qui est arrivé aux autres noms.

Cette discipline n’accorde aucun pouvoir nouveau au registre. Elle correspond au rôle le plus étroit d’un teneur de registre : publier un relevé dont l’identité est exacte. Les octets du 29 août peuvent être bons. Le contrôle peut être bon. Deux noms de 2023 ne l’étaient pas pour les objets qu’ils servaient.

Sources