Résumé

  • La fiche PeeringDB de l’ASN 33764 d’AFRINIC indique encore AS-AFRINIC sans préciser la source IRR, alors que l’évolution annoncée vise à rendre ces références plus faciles à résoudre.
  • Un préfixe peut guider la recherche vers un registre. Il ne démontre ni le contenu de l’AS-SET, ni l’autorisation, ni son actualité, ni son adéquation avec un filtre de routage.

Une indication n’est pas une chaîne de preuve

Sur la fiche réseau PeeringDB d’AFRINIC, identifiée par le numéro 3803, on trouve l’ASN 33764 et l’AS-SET IRR AS-AFRINIC. L’API publique expose la même valeur dans le champ irr_as_set. La page affiche aussi la mention « IRR AS-SET Verified ». Ce libellé décrit ce que PeeringDB présente à l’écran ; il ne fournit pas, dans les éléments publics examinés, l’historique de la requête, le registre interrogé, la date de vérification ou la liste des membres obtenue.

Les horodatages ne doivent pas être fusionnés. La fiche réseau porte une date générale de mise à jour au 2 mai 2025, tandis que les données de peering LAN ont leur propre date, le 26 mars 2026. Cette dernière ne prouve pas que le champ AS-SET a été modifié ce jour-là. La date générale plus ancienne ne suffit pas non plus à qualifier toute la fiche d’obsolète. L’historique propre à la valeur IRR n’apparaît pas dans les champs publics.

Le changement de PeeringDB répond à un problème plus circonscrit. L’issue #1973 signalait des noms impossibles à attribuer, d’autres présents dans plusieurs IRR et une étape de contrôle manuel avant l’automatisation. Les notes de la version 2.82.0, publiée le 19 août, annoncent un éditeur intelligent, la correction proactive des noms dont la source est sans équivoque et la prise de contact avec les responsables des cas ambigus. Le bilan de septembre donne AFRINIC::AS-AFRINIC comme exemple de nom qualifié et décrit cette prise de contact. Il documente une évolution et une démarche de nettoyage ; il ne dit pas pourquoi cette fiche précise conserve la forme courte.

Le préfixe change la recherche, pas le contenu

Un nom d’AS-SET renvoie à une entrée IRR ; il ne reproduit pas les membres qu’elle contient. La RFC 2622 décrit un ensemble composé de numéros d’AS ou d’autres noms d’AS-SET. Un outil qui lit PeeringDB peut se servir du champ pour choisir un IRR, récupérer l’enregistrement, développer ses membres, puis fabriquer un filtre. Si le même nom existe dans plusieurs bases, le préfixe indique plus clairement laquelle interroger.

Cette amélioration est réelle au premier maillon. Elle ne vérifie pas la chaîne entière. Un préfixe ne prouve pas que l’enregistrement existe encore, que ses mainteneurs sont habilités, que les membres reflètent la politique voulue ou que l’expansion récursive est complète. Il n’explique pas le traitement des renvois, des miroirs en retard ou des copies contradictoires. La chaîne de caractères, seule, ne permet pas de conclure que le filtre final correspond à l’intention de l’opérateur.

La distinction a un effet pratique. Un outil qui choisit le mauvais IRR, ou qui reçoit un ensemble vide ou partiel, peut produire un filtre qui écarte des routes attendues ou en admet d’autres. L’issue PeeringDB mentionne le risque d’erreurs dans les politiques de filtrage. La recherche ne trouve cependant aucun indice d’une telle erreur pour l’ASN 33764, d’un défaut dans l’IRR d’AFRINIC ou de l’utilisation de cette fiche dans un filtre actif. Un mécanisme de risque plausible n’est pas un incident constaté.

Rendre chaque étape vérifiable

Un processus prudent conserverait la fiche et sa version, la source IRR sélectionnée, l’heure de la requête, l’identité de l’enregistrement obtenu, le nombre de membres après expansion et une empreinte du résultat, puis le test de politique effectué en aval. La mention « vérifié » peut être utile, mais il faut en connaître le périmètre et la date pour la traiter comme une preuve exploitable. La page et l’API examinées exposent une étiquette et une valeur, pas cette chaîne.

AFRINIC::AS-AFRINIC, lorsqu’il est présent, signifie donc quelque chose de limité : où chercher. Il ne certifie pas la réponse. La valeur sans préfixe de la fiche AFRINIC rappelle que le répertoire, l’entrée IRR et la décision de routage relèvent de plans de contrôle différents. Le nom qualifié clarifie le relais ; le consommateur doit encore vérifier ce qui le franchit.

Sources principales : issue PeeringDB #1973, notes de version 2.82.0, bilan PeeringDB de septembre, fiche réseau AFRINIC, API publique, spécifications de l’API et RFC 2622.