Summary

  • In reproductions of the RIPE Database, "DFINFRA" is a role object with nic-hdl DA9499-RIPE, address New-York-Ring 6, 22297 Hamburg, Germany, maintainer EDDI-MNT, created on 2021-06-10 and referenced as both admin-c and tech-c of AS210860.
  • The same object layer attaches the autonomous system to organisation ORG-EDG14-RIPE — org-name EDEKA Verwaltungs- und Beteiligungs GmbH, org-type LIR, country DE, registry number Hamburg HRB 90516 — while a third-party reproduction labels the network EDEKA DIGITAL GmbH.
  • Hurricane Electric records one originated IPv4 prefix, 193.21.248.0/21, zero announced IPv4 prefixes, one observed BGP peer and no visibility in the global routing table since 26 March 2026; the CIDR Report lists the AS as "NOT Announced".

The registry layer stores a role, not a company

Read against the objects that can actually be inspected, "DFINFRA" is not a corporate name. It is a registry role: a contact handle that receives mail on behalf of whoever holds maintainer rights over a set of objects. In the reproductions available here, that role carries nic-hdl DA9499-RIPE, the address New-York-Ring 6, 22297 Hamburg, Germany, the maintainer EDDI-MNT and a creation date of 2021-06-10. The same role is listed as admin-c and as tech-c of aut-num AS210860, which means the registry treats it as the administrative and the technical point of contact for that number resource.

The RIPE Database query supplied for this verification is the anchor for that reading, and two mirrors of the same WHOIS payload reach the same conclusion: ip.cc and IPIP.NET both reproduce the role and the aut-num with matching handles and maintainers. None of them, and no other object inspected, names DFINFRA as a company, as the legal owner of the autonomous system, or as the operator of a commercial service built on it. The name appears in the registry as a contact identity inside EDEKA's administration — an administrative label, not a competitive position.

The aut-num object and its two named neighbours

The autonomous system object itself adds detail that is easy to over-read. Its as-name is "edeka_digital"; its organisation is ORG-EDG14-RIPE; it imports from AS9211 and AS13237 and exports to the same two ASNs; its status field reads ASSIGNED; and its maintainers are RIPE-NCC-END-MNT alongside EDDI-MNT. Those import and export statements describe routing policy intention addressed to two named counterparties, one of which — AS9211 — is also the single BGP peer Hurricane Electric observed for AS210860.

A policy statement of that kind is not evidence of live traffic, and the registry does not record volumes, contracts, customers or service levels.

Behind the object sits an organisation. ORG-EDG14-RIPE is recorded as org-name EDEKA Verwaltungs- und Beteiligungs GmbH, org-type LIR, country DE, with registry number Hamburg HRB 90516. A third-party reproduction instead attaches the prefix 193.21.248.0/21 to EDEKA DIGITAL GmbH. Both renderings appear in the same layer of public material, and the difference is not resolved by anything captured here.

Two registry views of one ASN do not agree

The registry layer is not internally consistent about this number resource. RIPE WHOIS reproductions render AS210860 with status ASSIGNED and an EDEKA organisation attached. RIPEstat, querying the same registry system, renders the ASN's RIR status as RESERVED with no registration or holder value, and separately reports that the AS does not originate prefixes visible in RIS and is not seen in RIS as transiting. One view implies an allocated, held resource with a named holder; the other implies a resource whose registration is empty. Nothing in the available material adjudicates which view is authoritative at which point in time, so the discrepancy is recorded here as unresolved rather than as proof of either state.

The observation layer reports a dormant network

The routing-observation record is more uniform than the registration record. Hurricane Electric's BGP toolkit counts one originated IPv4 prefix — 193.21.248.0/21, credited to EDEKA DIGITAL GmbH — and zero announced IPv4 prefixes, observes a single BGP peer in AS9211 (Nawork Internet Informationssysteme GmbH), reports no visibility in the global routing table since 26 March 2026, and records zero RPKI-originated-valid prefixes. The CIDR Report reaches the same practical conclusion in different words: the AS is "NOT Announced", not used to announce prefixes in the global routing table and not visible as a transit AS. An absence of observation over a bounded window is not proof that no equipment exists anywhere, but it is proof that no announcement was seen. For anyone assessing whether a network is carrying traffic, that distinction is the whole question.

The self-declaration that nothing else reproduces

The one record that describes a materially larger network is a self-declaration. A PeeringDB network record for AS210860 — as reproduced by HostDir, which attributes the fields explicitly to PeeringDB — lists the network under the name EDEKA DIGITAL with network type "Other", scope "Not Disclosed" and policy "Open", and credits it with ten IPv4 prefixes and one IPv6 prefix. A declaration of that kind describes what an operator says about itself; it does not measure what is announced. The captured observation sets report zero announced prefixes, one originated prefix and no global visibility, so the declared counts have no counterpart in the independent material. Which of the two is stale, and in which direction, cannot be determined from what is available.

What the record does not establish

Several limits are structural rather than incidental. Direct retrieval of the supplied registry query and PeeringDB URLs did not return their live content during this review, so the object fields above are reconstructed from third-party reproductions whose snapshot times are unknown. The role object's creation date of 2021-06-10 is a registry edit date and cannot be read as the start of any commercial activity. No filing, contract, invoice, customer document or regulator decision was available, so no revenue, customer, control or continuity conclusion can be drawn. Nothing here alleges wrongdoing by EDEKA, DFINFRA or any counterparty, and nothing here asserts that a network does or does not operate: it reports what registries and observation systems record, attributed to each. The same boundary applies to BTW's own directory entry for DFINFRA, whose service labels describe an administrative footprint that the public record inspected here does not extend into observed routing.