Summary

  • Public records can connect the DFINFRA label with AS210860 and identify several evidence layers for further testing, but each layer answers a different question.
  • The current evidence package does not establish live prefix counts, active peers, facilities, hosted services, customer relationships or a specific operator’s responsibility for continuity.

DFINFRA is a useful case because the public trail appears to promise more certainty than it can currently deliver. An autonomous-system number, a registry object and routing-oriented directories can make an organization look like a network operator. They do not, by themselves, show who runs routers, who can change announcements, where equipment is installed, which services depend on the network or who must restore it during an outage.

That distinction is not a technicality. It determines whether a reader is looking at an operating infrastructure provider, a resource holder, an administrative contact, a brand attached to a network, or an association that has persisted after the underlying arrangement changed.

The first evidence layer is administrative identity

The RIPE Database aut-num record and the corresponding RDAP representation are the formal starting points for AS210860. They can establish how the autonomous system is represented in the registry, which organization or contacts are associated with it, what maintainers and status fields are recorded, and how the record has changed over time. The relevant registry endpoints are the RIPE aut-num object and RIPE RDAP record.

A registry object is important evidence, but it is evidence of registration. It records an association between resources and named parties under registry procedures. It does not independently establish legal ownership, physical deployment, a current commercial service, or the identity of the person who would make a routing change at 03:00 UTC.

The practical test is therefore not whether DFINFRA appears in a registry. It is whether the registry identity can be joined to other, independently meaningful observations without treating the join itself as proof.

Routing visibility shows activity, not the whole operating model

The next layer is observation. RIPEstat’s announced-prefix data and ASN-neighbour data are designed to show what collectors observed: prefixes seen with AS210860 as an origin and autonomous systems appearing adjacent to it in observed paths. The RIPEstat AS210860 overview and the bgp.tools profile provide additional public views of the same general problem.

If a prefix is observed as originated by AS210860, that supports a bounded statement about routing visibility during a particular observation window. It does not prove that DFINFRA owns every address in the prefix, that it hosts every system reachable through it, or that it sells connectivity directly to the users of those systems. If another ASN appears beside AS210860, that supports an adjacency observation. It does not reveal whether the relationship is paid transit, settlement-free peering, a customer arrangement, a route-server path, a sibling relationship or an artifact of limited collector visibility.

Those distinctions matter especially for a small or recently established network. A sparse public footprint may mean limited deployment, selective announcement, incomplete observation, a private arrangement or a network that is no longer active. The observation alone cannot choose among those explanations.

Directories add leads, not operational accountability

PeeringDB’s network record, exchange-LAN records and facility records are potentially valuable because they can expose what an operator says about its network, policy, exchange presence or colocation footprint. They are not equivalent to a live BGP session, an equipment inventory, a customer contract or an incident record.

A self-reported facility entry can establish that a deployment was declared in a particular directory. It cannot, without corroboration, establish that equipment remains installed, that a port is carrying traffic or that the named organization controls the facility. An exchange-LAN entry can identify a declared interconnection point. It does not demonstrate that the session was active at the time a route was observed. Conversely, an observed route may be real even when the corresponding directory record is missing or stale.

This is why the most useful output of directory research is often a lead list: names, locations, policy statements and dates that can be checked against exchange membership, provider records, route observations and the operator’s own documents.

What deployment evidence would add

A stronger operational case would need evidence that connects several independent layers within a defined time window. One possible chain would include:

  1. a registry identity linking AS210860 to a named organization or responsible contact;
  2. technical authority over the relevant address or routing resources, such as consistent maintenance or authorization records;
  3. observed route origin and path visibility from multiple collectors;
  4. a corroborated physical or exchange presence;
  5. an identifiable service mechanism, such as a published network service, hosting deployment or customer-facing connectivity offer; and
  6. an attributable operational consequence, such as a documented withdrawal, recovery action, service interruption or response by the responsible operator.

The chain is deliberately demanding. Each item tests a different proposition. A route can be visible without proving who owns the equipment. A facility can be declared without proving a current session. A website can resolve into an announced prefix without proving that the ASN holder operates the website. A registry contact can exist without proving that the contact has operational authority today.

The deployment question should therefore be phrased as a set of tests rather than a verdict. Do the same actors recur across the registry, routing, interconnection and service layers? Do timestamps align? Are the observations reproducible from more than one collector? Does a named organization describe the service in a way that matches the network evidence? When something changes, is there a public record showing who made the change or assumed responsibility?

The public record’s present boundary

The current evidence package identifies the relevant sources and preserves their limitations. It does not provide a verified live measurement of the number of prefixes announced by AS210860, its current upstreams or peers, its active exchange ports, its facility presence, the services visible on its address space or the business consequences of an outage. The RIPEstat overview and routing datasets should be read as time-bounded observations, not as a permanent description of the network.

That boundary is itself a finding. Previous coverage has already explained why registry identity, route authorization, BGP visibility and continuity should not be merged into a single claim. The additional question here is how a deployment could be demonstrated: what evidence would move the investigation from “this ASN is visible” to “this identifiable actor operates this service through these dependencies and bears this consequence when the service fails.”

At present, the public material defines that test more clearly than it satisfies it. The responsible conclusion is not that DFINFRA has no operating network. It is that the supplied evidence does not yet justify attributing a complete deployment, commercial role or continuity responsibility to DFINFRA.

A reproducible next step

A future update should use dated requests and preserve the raw responses. It should compare the RIPEstat prefix and neighbour results with an independent routing view such as RIPE RIS or the Route Views archive, then reconcile differences by collector and observation time. It should inspect the registry and directory records for modification dates, compare any declared exchange or facility presence with the relevant operator’s records, and treat web or host observations as deployment correlations rather than ownership proof.

The investigation should also look for an accountable action. A route change with a timestamp is not enough unless it can be connected to a responsible party. A documented service announcement is not enough unless the service can be connected to the observed infrastructure. The decisive evidence would be a coherent, time-bounded chain in which identity, authority, deployment and consequence point to the same actor.

For readers assessing infrastructure risk, this is the useful result. A registry label can tell you where to start. Routing data can show what was visible. A directory can reveal what someone declared. None of those alone tells you who will answer for the network when the path disappears.

Sources used for the evidence framework include CAIDA AS Rank, RIPE Database route search, RADB, Cloudflare RPKI data, and the DFINFRA BTW directory record. These references identify evidence layers and investigative leads; they do not convert uninspected or time-sensitive data into stronger claims than the record supports.