Résumé

  • AS210860 n'a annoncé aucun préfixe dans la table de routage mondiale depuis le 26 mars 2026, un constat corroboré indépendamment par Hurricane Electric, RIPEstat et CIDR Report.
  • Deux miroirs indépendants du RIPE Database reproduisent un objet aut-num identique : status ASSIGNED, as-name edeka_digital, organisation ORG-EDG14-RIPE, inchangé depuis le 27 octobre 2021.
  • Les miroirs se contredisent sur le nom de l'organisation (EDEKA Verwaltungs- und Beteiligungs GmbH contre EDEKA DIGITAL GmbH) et sur sa date de dernière modification (13 mai 2026 contre 27 octobre 2021).
  • RIPEstat rend le statut du réseau comme RESERVED sans titulaire — une valeur que la documentation de référence du RIPE exclut comme statut d'aut-num, ce qui plaide pour une différence de couche de données plutôt que pour un changement registriel.
  • Aucun objet de route n'est apparu dans aucune des sorties consultées, et la chaîne entre enregistrement et contrôle opérationnel demeure non prouvée.

Le point de départ : une chaîne définie en septembre, jamais fermée

En septembre 2026, trois enquêtes de BTW sur DFINFRA et l'AS210860 avaient posé la même architecture d'analyse : séparer quatre couches de preuve — ce qui est enregistré, ce qui est autorisé, ce qui est observé et ce qui est contrôlé. La conclusion du dossier sur la chaîne de contrôle était explicite : le paquet de recherche de l'époque n'exposait pas les valeurs de champ en direct, notamment l'état actuel des ROA et le contenu des objets de route. Le briefing sur l'état nul et l'analyse de l'état de septembre reconnaissaient la même limite : tous les faits registriels cités étaient fondés sur des miroirs, l'endpoint de référence du RIPE n'ayant renvoyé qu'une coquille applicative.

La question de cette enquête était étroite : depuis ces publications, quelque chose a-t-il changé dans l'état observable ? Et si oui, cela referme-t-il une partie de l'écart entre enregistrement et contrôle opérationnel ? La fiche d'objet correspondante du répertoire BTW est disponible ici : [https://btw.media/fr/directory/dfinfra].

Le routage : le silence se confirme, daté et tri-source

Trois observateurs indépendants décrivent le même état. Selon la page de l'AS sur Hurricane Electric, l'AS210860 n'est plus visible dans la table de routage mondiale depuis le 26 mars 2026, avec zéro préfixe annoncé actuellement, zéro entrée RPKI-valide et zéro entrée RPKI-invalide, et un seul préfixe historiquement origine : 193.21.248.0/21, attribué à EDEKA DIGITAL GmbH [https://bgp.he.net/AS210860]. RIPEstat, le service d'analyse du RIPE NCC, indique pour sa part que l'AS n'origine pas de préfixes visibles dans RIS et n'apparaît pas comme AS de transit, avec un panneau de détails de préfixes vide [0]. CIDR Report le classe indépendamment comme « NOT Announced » : non utilisé pour annoncer des préfixes ni comme AS de transit visible [https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0]. La page v4 dédiée du même miroir confirme le même historique d'origine sur la seule plage 193.21.248.0/21 [https://ipv4.bgp.he.net/AS210860].

La convergence des trois sources sur l'absence est le fait le plus solide de ce dossier. Elle n'est pas neuve — elle confirme l'état déjà documenté en septembre — mais elle établit que ce silence dure et se prolonge sur l'ensemble de la période intermédiaire.

L'objet registriel : deux miroirs concordent verbatim, l'endpoint de référence reste illisible

Le changement méthodologique le plus significatif de ce passage de recherche concerne la couche registrielle. Pour la première fois dans cette série, deux miroirs indépendants du RIPE Database ont renvoyé un bloc RPSL largement verbatim, et les deux reproduisent le même objet aut-num :

aut-num AS210860, as-name edeka_digital, org ORG-EDG14-RIPE, status ASSIGNED, mnt-by RIPE-NCC-END-MNT et EDDI-MNT, créé le 24 août 2021, dernière modification le 27 octobre 2021, source RIPE.

Le premier miroir, whois.ipip.net, renvoie ce bloc ainsi que les déclarations d'import/export symétriques vers AS9211 et AS13237 [https://whois.ipip.net/AS210860]. Le second, ip.cc, reproduit des champs identiques [https://ip.cc/topic/asn/AS210860/]. Le rôle DFINFRA (nic-hdl DA9499-RIPE), contact administratif et technique de l'aut-num, y figure créé le 10 juin 2021 et inchangé depuis le 27 octobre 2021 [7].

En face, l'endpoint de référence — l'interface web du RIPE Database pour l'objet aut-num [https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num] — a de nouveau renvoyé une coquille applicative sans valeurs de champ, comme lors de la couverture de septembre. L'application étant rendue côté client par JavaScript, la lecture directe du contenu RPSL n'a pas abouti dans cette session. Nous le formulons sans détour : aucune valeur de champ de cet article n'est une lecture de première main du registre. Toutes proviennent de miroirs datés ou de services d'observation, et la documentation du RIPE décrit l'API REST de la base comme la voie lisible par machine — paramètres unfiltered et unformatted, sortie JSON, historique de versions par objet [https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries] — sans que cette voie ait pu être testée ici.

Là où les miroirs se disputent : nom d'organisation et date de modification

Les deux miroirs concordent sur l'aut-num mais divergent sur l'objet organisation ORG-EDG14-RIPE. whois.ipip.net rend org-name « EDEKA Verwaltungs- und Beteiligungs GmbH » avec une dernière modification datée du 13 mai 2026 [2] ; ip.cc rend « EDEKA DIGITAL GmbH » avec une dernière modification datée du 27 octobre 2021 [7]. Ces deux divergences — nom et horodatage — portent sur le même identifiant d'objet. Ni l'une ni l'autre ne peut être tranchée sans lecture de première main, et la couverture antérieure de BTW sur le cycle de vie de l'AS avait déjà relevé ce nœud sans le résoudre [9].

Une lecture prudente s'impose : la valeur du 13 mai 2026 sur un miroir pourrait refléter un changement de nom, une fusion, une mise à jour d'attribut ou une copie différemment filtrée. Aucun des miroirs n'expose sa date d'instantané. Ériger l'une des deux org-names en fait présent de registre serait précisément l'erreur que la méthode de septembre interdisait.

L'énigme RIPEstat : un statut que la documentation exclut

La divergence la plus instructive ne vient pas des miroirs mais d'un service exploité par le RIPE NCC lui-même. Sur un instantané daté du 14 septembre 2026, RIPEstat rend l'AS210860 avec le statut RESERVED et un champ titulaire vide (« Name and holder of this ASN: - ») [https://stat.ripe.net/resource/AS210860]. Or la documentation de référence des objets primaires du RIPE Database est formelle : l'attribut status d'un aut-num est généré par logiciel et ne peut prendre que trois valeurs — ASSIGNED, LEGACY ou OTHER — qu'aucun utilisateur ne peut fixer ni modifier [https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/].

RESERVED n'appartient pas à ce vocabulaire. La conclusion la plus économique est donc que RIPEstat et les miroirs lisent deux couches de données différentes — l'une descriptive du statut de ressource côté registry-information, l'autre l'objet aut-num lui-même — et que la divergence est un artefact de rendu, non un changement registriel. Un agrégateur de plus faible fidélité, ipgeolocation.io, aggrave le tableau en nommant le RIPE NCC lui-même comme organisation et en affichant « Date Allocated: N/A » [https://ipgeolocation.io/browse/asn/AS210860] ; l'écart de sa plage d'as-block (2026-07-13) avec celle du miroir ipip (2026-02-12) illustre combien ces vues secondaires diffèrent d'une couche à l'autre.

Ce qui reste ouvert : les objets de route et la chaîne de contrôle

La documentation du RIPE confirme un point structurel : les préfixes ne sont pas des attributs de l'aut-num ; ils se lient par des objets route et route6 distincts, autorisés via les maintainers mnt-routes ou, à défaut, mnt-by [9]. Or aucun objet de route n'est apparu dans aucune sortie de miroir consultée — ce qui ne prouve pas leur absence, l'interrogation par clé d'AS ne les retournant pas ; leur existence réelle exige une recherche par origine inverse que cette session n'a pas exécutée.

Le bilan est donc net sur une moitié, inchangé sur l'autre. Le fait observé — absence de routage depuis le 26 mars 2026, attestée par trois sources indépendantes [0][1][4] — est stable et s'étend. Le fait registriel — ASSIGNED, as-name edeka_digital, org ORG-EDG14-RIPE — est désormais attesté par deux miroirs concordants verbatim [2][7], un degré de corroboration supérieur à septembre. Mais l'endpoint de référence reste illisible [6], les miroirs divergent sur l'organisation, RIPEstat reste en contradiction apparente [0], et rien de tout cela ne rapproche d'un pouce la question que septembre avait laissée ouverte : qui peut faire fonctionner ce réseau, changer ses annonces et en assumer les conséquences commerciales. L'IPinfo confirme, dans son propre cadre, l'étiquette Inactive et zéro préfixe pour le titulaire EDEKA Verwaltungs- und Beteiligungs GmbH [https://ipinfo.io/AS210860], sans trancher les conflits d'identité.