Summary

  • AS210860 remains absent from the global routing table: zero announced prefixes (IPv4 and IPv6) since 26 March 2026, with a single historically originated prefix, 193.21.248.0/21, and one observed peer, AS9211.
  • The RIPE Database aut-num AS210860 and the DFINFRA role object (nic-hdl DA9499-RIPE) remain last-modified 27 October 2021 per both mirrors retained here.
  • The new finding of this check is internal to the mirror layer: IPIP.NET renders the organisation object ORG-EDG14-RIPE as EDEKA Verwaltungs- und Beteiligungs GmbH (District court Hamburg HRB 90516), last-modified 2026-05-13, while ip.cc renders the same object as EDEKA DIGITAL GmbH, last-modified 2021-10-27.
  • The PeeringDB-derived record still self-declares ten IPv4 prefixes, one IPv6 prefix and an open peering policy, contradicting all routing observations.
  • The authoritative RIPEstat data endpoints and the RIPE Database query for DA9499-RIPE were again not directly retrievable, so every registry value in this article remains second-hand.

The routing state of AS210860 has not changed. Hurricane Electric's BGP toolkit listing, page updated 14 July 2026, reports zero announced prefixes, zero RPKI-valid and zero RPKI-invalid originations, and a single observed peer, AS9211 (Nawork Internet Informationssysteme GmbH) (Hurricane Electric). CIDR Report lists the same AS under the name EDEKA_DIGITAL, DE, with the status heading "NOT Announced" (CIDR Report). RIPEstat's rendered resource page, whose displayed data is dated 2026-09-14 00:00:00 UTC, reports no RIS-visible originations, no transit visibility, and renders the RIR registration status as RESERVED with no holder named (RIPEstat). The routing-status endpoint documentation confirms this is the machine-readable source observers are meant to query, but the live JSON payload for AS210860 was not directly retrieved in this run (routing-status).

The registry picture, as reproduced by third-party mirrors, is stable in structure. The aut-num carries as-name edeka_digital, the organisation reference ORG-EDG14-RIPE, status ASSIGNED, admin-c and tech-c both DA9499-RIPE, and maintainers RIPE-NCC-END-MNT and EDDI-MNT; it was created 24 August 2021 and last modified 27 October 2021. The DFINFRA role object (nic-hdl DA9499-RIPE) was created 10 June 2021 and last modified 27 October 2021, maintained by EDDI-MNT. Both mirrors agree on these fields (IPIP.NET) (IP.CC).

What the mirrors do not agree on is the organisation object. The IPIP.NET mirror renders ORG-EDG14-RIPE as org-name EDEKA Verwaltungs- und Beteiligungs GmbH, with district court Hamburg HRB 90516, last-modified 2026-05-13. The ip.cc mirror reproduces the same aut-num identically but renders the same organisation object as EDEKA DIGITAL GmbH, last-modified 2021-10-27. These are two different legal names and two different dates for one RIPE organisation handle. Neither mirror exposes its snapshot time, and the authoritative RIPE Database query for DA9499-RIPE returned only an interface shell in this run (RIPE Database). The announced-prefixes endpoint, the free and reproducible method RIPE NCC documents for verifying what an ASN announces, likewise produced no directly inspectable payload (announced-prefixes).

This matters because the reconciliation problem has changed shape. Prior BTW coverage, published between 26 and 30 September 2026, documented two contradictions: routing observations against a self-declared peering profile, and a frozen registry against a market surface promising ten prefixes (BTW state-difference). A third contradiction now sits one layer down: the mirrors that substitute for the authoritative record contradict each other about the identity of the organisation holding the resources. Prior reporting also traced the lifecycle of the silent network and its contact objects (BTW lifecycle ledger).

The verification cost, which earlier articles placed on any peer, registry consumer or observer who wants a reconciled picture, is now compounded: before reconciling self-declaration against routing, a diligent consumer must first decide which mirror's rendering of the organisation object to trust, and the public record offers no basis for that decision. The open question this article leaves standing: which rendering of ORG-EDG14-RIPE reflects the live RIPE Database, and what does it mean for verification cost when the substitute verification layer disagrees with itself on a name and a date?

For completeness, the disambiguation established in prior coverage holds: DFINFRA is a RIPE Database role object name, not a trading company; the organisation behind the registration is rendered variously as EDEKA Verwaltungs- und Beteiligungs GmbH (Hamburg HRB 90516) and EDEKA DIGITAL GmbH; and DINFRA GmbH of Siegen is a different legal entity that must not be conflated with any of these.

Directory record: https://btw.media/en/directory/dfinfra