Summary

  • Public registry records associate the DFINFRA label with AS210860, but registry identity is administrative evidence rather than proof of beneficial ownership, operational control or continuous service.
  • A defensible operating-footprint finding would need time-bounded corroboration across registry authority, routing observations, physical or exchange presence, a service mechanism and an attributable operational or commercial consequence.

The difficult part of investigating a small or lightly documented autonomous system is not finding a name. It is refusing to treat several different kinds of evidence as if they were one fact.

A registry can associate an organisation name with an autonomous system number. A route object can declare that the number is authorised to originate a prefix. RPKI can provide a cryptographic statement about route-origin authority. A route collector can observe an announcement from some vantage points. A peering database can list a facility, exchange or contact. None of those observations, alone, proves that the named organisation owns the address space, operates routers, sells connectivity, serves customers or would be responsible for restoring service after a failure.

That distinction is the central finding in the available public record for DFINFRA and AS210860. The evidence defines a rigorous investigation path, but the current research package does not close it with live measurements or an independently documented service mechanism.

The first link is administrative, not operational

Public registry material associates the DFINFRA label with AS210860. The relevant starting points are the RIPE RDAP record for AS210860 and the RIPE Database aut-num object. The IANA AS-number registry provides the top-level allocation context.

Those records can establish how an autonomous system is represented in registry systems, which registry is authoritative for the number and which administrative objects or contacts are attached to it. They do not, without additional evidence, establish who ultimately benefits from the resource, who operates equipment, who can change routing policy or whether a customer-facing service exists.

This is not a technicality. Administrative identity and operating control can diverge for legitimate reasons. A network may use a provider's infrastructure, announce resources under delegated authority, maintain a dormant registration, operate only briefly, or rely on an organisation whose public name differs from its commercial or technical operator. A registry record is therefore a lead into the control question, not its answer.

Route authorisation is not route operation

The next layer concerns what AS210860 is authorised or declared to do. A reverse search for RIPE Database route and route6 objects can identify IRR assertions that the ASN is an origin for particular prefixes. RPKI data, including the Cloudflare RPKI dataset, can help test whether route-origin authorisations exist and whether they are consistent with observed announcements.

These are important controls, but they answer different questions. An IRR object is a database assertion about routing intent or authorisation. An RPKI record is a cryptographically signed authorisation statement. Neither one proves that a route is currently announced, that the registrant owns the address block, or that a service is being delivered to users.

The distinction becomes especially important when a public profile is treated as evidence of a network business. A valid authorisation can coexist with no current announcement. A route can be visible without proving that the ASN registrant owns the underlying address resource. A prefix can be assigned, suballocated or originated under another party's authority. The evidence must therefore be kept in separate columns: resource identity, route-origin authority and observed routing activity.

What routing observations can—and cannot—show

The RIPEstat AS Overview, announced-prefixes endpoint, routing-status endpoint, ASN-neighbours data and looking-glass paths are candidate sources for the live routing layer. Independent cross-checks are available through BGP.Tools, Cloudflare Radar, CAIDA AS Rank, Hurricane Electric's AS page, BGPView upstream data and RIPE RIS.

Used with timestamps and collector coverage, these sources can show whether an ASN or prefix was visible from particular measurement systems, which ASNs appeared adjacent in collected paths and whether observations changed over time. That can support a bounded statement such as: a route was observed from a specified collector at a specified time, or an adjacent ASN recurred in the available path sample.

It cannot, by itself, establish the commercial meaning of the adjacency. A neighbouring ASN may be a paid transit provider, a settlement-free peer, a customer, a sibling network, a route server or a backup path. AS paths show propagation, not contract terms. Different collectors can produce different results, and a missing observation is not proof that a route or session does not exist.

For DFINFRA, the crucial live values would be the current prefixes, observation times, visibility levels, path samples and changes across independent collectors. The research package did not retrieve those live contents. It therefore does not assert a current prefix count, a named upstream, a named peer or a measured dependency on one provider.

Self-reported presence is a separate evidence class

PeeringDB can add operational context, but it must be read as a different class of evidence. The PeeringDB network record, network page, exchange-LAN records and PeeringDB documentation may contain an operator-selected network name, policy, contact information, facility listings, exchange participation or port details.

That information can be useful because it identifies claims made by a network operator about its intended presence. It is not independent proof that equipment remains installed, that a port is active, that bilateral sessions exist with every exchange member or that the listed organisation legally owns the infrastructure.

The correct test is corroboration. A facility claim becomes stronger when it aligns with a current exchange member record, an observed route or session, an operator statement and a time-bounded technical measurement. A listed exchange presence that never appears in route observations may reflect a dormant, selective or transparent route-server arrangement—but it should not be silently converted into proof of active connectivity.

The missing service mechanism

The most consequential gap is not a missing label or an incomplete routing table. It is the absence, in the available package, of an independently documented mechanism explaining what DFINFRA provides.

A service mechanism would connect the network identity to something users or counterparties can actually consume: an access product, hosting or transport service, a published interconnection offering, a documented customer relationship, a network operations contact with a defined responsibility, or another independently verifiable operational function. The relevant evidence could come from technical documentation, customer records, facility or exchange records, contractual disclosures, incident reports or consistent measurements linked to a named operator.

The current research package assembled high-relevance public source candidates but did not retrieve their live contents. It therefore does not establish a DFINFRA service, customer base, revenue stream, facility, exchange, route set or operational incident. The absence of such a finding is not proof that no service exists. It is a limit on what this evidence package can responsibly say.

That boundary matters because commercial conclusions are often smuggled into technical descriptions. An ASN is described as a provider because it appears beside another ASN. A facility listing is described as owned infrastructure. A route announcement is described as a customer service. A registry name is described as the operator. Each step may be plausible; none is established without the missing link that identifies the actor, capability and consequence.

A practical test for operational control

A stronger finding about DFINFRA and AS210860 would require a chain of evidence that is both time-bounded and attributable.

First, the registry layer would identify the relevant administrative objects, entities, maintainers and modification history through RDAP and the RIPE Database object.

Second, the authority layer would distinguish IRR declarations from RPKI authorisations using the route-object search and RPKI data. The question would be who can maintain or authorise the relevant objects, not merely whether an object exists.

Third, the observation layer would record actual announcements, visibility and paths from RIPEstat, RIS and independent collectors such as BGP.Tools or Cloudflare Radar. Every value would need a query or observation time.

Fourth, the physical or exchange layer would test any PeeringDB claim against independent exchange information, route observations and operator documentation. A facility name alone would remain a claim, not a verified deployment.

Fifth, the service layer would identify what the network does for a customer, partner or public system. This is where documentation, contracts, product pages, incident records or attributable testimony become necessary.

Finally, the consequence layer would connect the operating capability to a measurable result: a route change, a service interruption, a recovery action, a customer-facing effect or an independently documented commercial relationship. Only then could the investigation move from “this ASN appears in the public control plane” to “this identifiable actor operated or controlled this function during this period.”

Why dependency claims need restraint

Dependency is not synonymous with adjacency. A network can appear next to another ASN in an AS path without relying on it as a paid upstream. A route can be visible through one collector and absent from another without indicating failure. A listed exchange can provide optionality without proving an active path. Conversely, a network can be operationally dependent on a provider whose ASN is not obvious in a limited sample because of route servers, selective propagation or incomplete collector coverage.

The useful dependency question is therefore conditional: which function would fail or degrade if a specific relationship disappeared, and what evidence demonstrates that relationship? That may require repeated observations, directionality, route changes, provider documentation and a defined service consequence. It cannot be inferred from a single neighbouring ASN or a generic “upstream” label.

For DFINFRA, the available material supports the design of that test. It does not provide enough live, independently corroborated data to rank dependencies, identify a single point of failure or describe continuity arrangements.

What the public record currently supports

The defensible conclusion is narrower than either a network profile or a claim of non-operation.

The public record associates DFINFRA with AS210860 in registry material. It identifies a set of technical and operational evidence classes that could be combined to investigate authority, routing visibility, interconnection and service delivery. It also shows why those classes must not be collapsed into ownership, customer, revenue or continuity claims.

What it does not currently establish is a current prefix inventory, a named upstream or peer, an active facility or exchange presence, a valid route-origin authorisation tied to a live announcement, an independently documented DFINFRA service mechanism or an attributable outage and recovery sequence. The evidence boundary is therefore not “DFINFRA has no network.” It is: the available material has not yet demonstrated what operational function DFINFRA performs, through which dependencies, or with what consequence.

The next useful investigation would not be another repetition of the registry association. It would be a dated, multi-source observation that links one identifiable actor to one technical authority, one observed routing function, one physical or exchange footprint and one service or operational consequence. Until that chain is closed, AS210860 remains an investigative lead rather than proof of a customer-facing network business.

Sources and evidence boundaries

This article uses the following FACT_PACKAGE source set. Dynamic routing and third-party profile sources require live retrieval, timestamps and collector context before current values are asserted.

The subject's BTW public profile is a reader-facing reference page. It is not evidence of any additional operational fact.