Summary

  • DFINFRA’s association with AS210860 is an investigative lead, not independent proof of legal ownership, maintenance authority, route origination or operational control.
  • The relevant evidence layers are identifiable: the RIPE aut-num record, IRR route objects, observed BGP announcements, routing-status data and RPKI validation. The current research package does not expose the live field values needed to connect those layers.

A name in an Internet number-resource record is often the first visible clue in an infrastructure investigation. It can point researchers toward an autonomous system, a set of route objects or a change in stewardship. But the name does not answer the questions that matter most to operators, investors and public-interest investigators: who controls the resource, who can change its routing policy, whether the system is active, and whether it delivers a service on which other parties depend.

That distinction is central to the DFINFRA–AS210860 case. Earlier BTW coverage established that public records associate DFINFRA with the autonomous system number AS210860. It also separated four different forms of evidence: administrative registry information, route authorization, observed BGP activity and RPKI validation. The new investigation was designed to test whether those layers could be independently connected and whether the association could be advanced from a registry signal to evidence of effective operational control.

It could not complete that connection.

The result is not that DFINFRA has no relationship to AS210860. Nor is it that AS210860 is inactive. The result is narrower and more useful: the current research execution did not independently retrieve the live values required to establish what the relationship means in operational terms.

What the public record can signal

The starting point is the RIPE Database aut-num record for AS210860: the RIPE Database object for AS210860. An aut-num record is a registry instrument. It can contain an autonomous-system name, organisational references, contacts, maintainers, status information and timestamps. Those fields can show how a resource is represented in a registry and who is listed around it.

They do not, on their own, demonstrate that the named party is the legal owner of an organisation, the current operator of a network, the party originating routes, or the party capable of making technical changes. A registry record answers an administrative question. It does not automatically answer an operational one.

The distinction matters because names can play different roles. A party may appear as a contact, a maintainer, an organisation reference or a descriptive label. Those roles may overlap, but they are not interchangeable. A contact record can be accurate while saying little about who runs equipment or controls upstream relationships. Conversely, routing activity can be visible without proving who owns the entity that appears in an administrative record.

Earlier coverage therefore treated DFINFRA as a lead for further investigation rather than as a proved operator. That is the appropriate baseline for the current article as well.

The second layer: authorization is not activity

The next test is the RIPE inverse-origin search for route and route6 objects associated with AS210860: the RIPE route-object search. IRR objects can record an asserted relationship between a prefix and an origin autonomous system. Their maintainer fields can indicate who is authorized to modify the object in that registry.

That evidence is valuable, but it answers a specific question: what routing policy has been recorded or authorized in the relevant database? It does not prove that the prefix is currently announced. A route object can remain in a registry after an announcement has stopped. A prefix can be announced while lacking a matching object in that particular database or while being represented elsewhere. The object’s maintainer also need not be identical to the maintainer or contact listed on an aut-num record.

This is why the route-object test cannot be collapsed into the ownership test. It can strengthen or weaken a hypothesis about authority, but it cannot by itself establish current service delivery or effective control.

The current evidence package identifies the RIPE inverse-origin endpoint as a required source for that comparison. It does not provide a verified current route object, prefix, maintainer or object date. No responsible conclusion can therefore be drawn about which prefixes, if any, are currently authorized to originate from AS210860.

The third layer: what collectors actually observe

Operational evidence begins with observation rather than registration. The RIPEstat announced-prefixes endpoint is intended to show prefixes observed as originated by AS210860 at a defined query time: RIPEstat announced prefixes. Its routing-status endpoint addresses whether the ASN is visible in routing data and can provide related timing or visibility information: RIPEstat routing status. The BGP-state endpoint offers another view of collector-level routing conditions: RIPEstat BGP state.

These sources answer different versions of the same operational question. They can help establish whether an ASN is visible from particular collectors, which prefixes are seen, when an observation was made and how an AS path is represented. They are stronger evidence of routing activity than a static registry label.

They still do not establish legal ownership. Nor do they necessarily establish that a party named in a registry controls the observed announcements. Visibility is also vantage-dependent. Different collectors can see different routes, and an ASN appearing in an AS path does not necessarily mean it is the origin of the route. Even an observed origin announcement proves routing visibility at a given time, not the full chain of organisational control behind it.

The current research package records that these endpoints were selected for verification but that live retrieval was unavailable in the research execution environment. The latest research receipt reports an incomplete verification status and an empty set of independently verified current facts. As a result, this investigation cannot state a current prefix count, a current routed or unrouted status, a collector observation, an AS path or a first-seen or last-seen date for AS210860.

That is a meaningful boundary. It prevents the article from turning a list of evidence candidates into a list of asserted network facts.

RPKI adds cryptographic authorization, not corporate identity

The fourth layer is routing security. The RIPEstat RPKI history endpoint is a candidate source for examining route-origin authorization over time: RIPEstat RPKI history. Independent routing views from BGP.Tools and Hurricane Electric can provide additional observational cross-checks: BGP.Tools’ AS210860 view and Hurricane Electric’s BGP Toolkit entry.

RPKI is particularly easy to overstate. A valid result means that a validated route-origin authorization covers a particular prefix and origin pair within the applicable prefix-length constraints. An invalid result can indicate an unauthorized origin or an announcement that exceeds a ROA’s maximum length. NotFound means that no applicable validated authorization was available. None of those states, by themselves, identifies the legal owner of DFINFRA, proves who operates AS210860 or establishes that a commercial service is being delivered.

RPKI and IRR are separate systems. An IRR route object can exist without a matching current ROA, and a ROA can authorize an origin without proving that the corresponding route is currently visible. A historical RPKI state also cannot be treated as a current one without its observation time and validation context.

The current package contains no prefix-specific ROA, authorized-origin, maximum-length, validity interval or validation-state finding. It therefore cannot support a claim that any AS210860 route is currently RPKI-valid, invalid or not found.

What the failed verification does—and does not—mean

The phrase “live retrieval was unavailable” should not be confused with evidence that the network is absent, inactive or misconfigured. It describes a limitation of this investigation’s verification path. The relevant public endpoints were identified, refreshed as research candidates and preserved as source artifacts, but the execution environment did not expose their current payload values for independent examination.

That limitation has three consequences.

First, the article cannot responsibly repeat an exact registry field as a current fact unless that field was independently retrieved and preserved. The source URL alone is not evidence of what its current response contains.

Second, the article cannot convert an expected comparison into a completed one. The intended comparison was between the aut-num record, route authorization, observed announcements and RPKI status. Without the live values, the comparison remains a research plan, not a result.

Third, the unresolved status does not erase the investigative signal. DFINFRA remains a name that warrants monitoring in connection with AS210860. Changes in the relevant registry records, route objects, observed prefixes or RPKI state could materially change the assessment. But monitoring a signal is not the same as proving control.

The public directory entry for DFINFRA is therefore best read as a subject record and an index for continued verification, not as a substitute for evidence of operation: DFINFRA in the BTW directory. The directory link helps readers locate the subject; it does not transform the subject’s registry association into a verified corporate or technical conclusion.

A practical evidence ladder for operators and investigators

A stronger finding would require several independent links to align.

The first link would be a current registry record showing the exact role DFINFRA plays in relation to AS210860: contact, organisation reference, maintainer or another field. The second would be current authorization evidence showing whether route or route6 objects associate specific prefixes with the ASN and identifying the relevant maintainers. The third would be time-bounded BGP observation showing which prefixes are actually originated by AS210860 and from which measurement vantage points.

The fourth would be prefix-specific RPKI evidence showing whether the observed origin is authorized, unauthorized or outside the scope of a validated ROA.

A fifth link would still be needed for an organisational conclusion: independent corporate, contractual, technical or customer evidence connecting the registry identity to the party capable of directing changes. Even a complete routing chain would not automatically prove legal ownership or commercial service delivery.

This layered approach is slower than reading a name from a registry and assigning it an institutional role. It is also more defensible. It distinguishes four questions that are often merged in infrastructure reporting:

  1. Who is listed in the administrative record?
  2. Who is authorized to represent or modify a routing object?
  3. What routes are observable on the Internet, and when?
  4. Who has effective organisational and technical control over the resource?

Each question needs its own evidence. The same name may appear across several layers, but repetition is not independence. A conclusion becomes stronger when the layers are separately sourced and then connected through evidence rather than assumed to be connected because they share a label.

The operational and economic implication

For infrastructure buyers, counterparties and risk teams, the unresolved boundary is not merely a research inconvenience. It defines what can and cannot be priced into a dependency assessment.

A verified registry association can justify monitoring. A verified route authorization can inform change-control and abuse-response analysis. Observed BGP activity can indicate reachability or exposure during a defined window. RPKI status can inform route-origin risk. None of those findings alone establishes that DFINFRA provides a service, that AS210860 supports a customer dependency, or that a particular party can restore connectivity after a failure.

Until those links are independently established, a prudent assessment should classify the DFINFRA–AS210860 relationship as an unresolved infrastructure signal. That classification avoids two opposite errors: dismissing a potentially important stewardship change because the evidence is incomplete, and presenting a registry reference as proof of an operating network.

The next useful update would not be another restatement of the association. It would be a time-stamped comparison that publishes the exact relevant registry fields, route objects, observed prefixes, collector window and prefix-specific RPKI results, while clearly attributing each conclusion to its source. If those layers converge, the operational-control hypothesis becomes stronger. If they diverge, the divergence becomes the story.

For now, the most supportable conclusion is narrower: DFINFRA and AS210860 remain linked by a public registry signal worth investigating, while the evidence needed to establish active operational control has not been independently verified in this research run.