Summary

  • The public evidence package identifies the records needed to test DFINFRA’s relationship with AS210860, but its current endpoint values were not independently retrieved in this research run. No responsible conclusion about active operational control follows from the available material.
  • A defensible control finding would require the same actor to be connected across administrative identity, routing authorization, observed BGP behavior and a demonstrable ability to cause or reverse a routing change. Even then, the commercial consequence would depend on what services, contracts and customers sit behind that capability.

The central mistake in investigating a network resource is to treat every public signal as if it answered the same question. A registry answers an administrative question. An IRR object records a routing assertion. RPKI records an authorization relationship. BGP observations show that routes were visible to particular collectors. Peering and transit records describe a claimed or inferred connectivity position. None of those layers, by itself, identifies the organization that can issue the next router instruction.

For DFINFRA and autonomous system number AS210860, that difference is the substance of the investigation. Earlier coverage established that the name’s appearance in public records is a legitimate starting point but not proof of ownership, operation or control. The additional question here is economic and operational: what would have to be true before that association could support a claim that DFINFRA controls a meaningful part of the digital-infrastructure chain?

The answer is narrower than a company profile. Control would need to be demonstrated as a chain of capabilities: a current identity connected to the resource; authority over the relevant registration or delegated maintenance; routing authorization for the prefixes in question; observed origination or other BGP activity; and evidence linking the ability to change that activity to DFINFRA rather than to a sponsor, transit provider, managed-network operator or successor. The chain also needs a time dimension.

A registry change and a route event occurring near one another may justify further testing, but proximity alone does not establish causation.

The current research package does not expose the live field values needed to close that chain. The retained material consists of immutable source snapshots and a source-bound assessment of what each endpoint can establish. The snapshots’ current payload values were not verified for this article. That is not a finding that AS210860 is inactive, nor a finding that DFINFRA lacks authority. It is a boundary on what can responsibly be said now.

What the registry can establish

The first layer is administrative identity. The public RDAP endpoint for AS210860 is the authoritative place to inspect the registered name, associated entities, status notices and registration or change events RDAP autnum record. The RIPE Database aut-num object provides a related administrative view, including the as-name, organization handle, contacts, maintainers, status and declared routing policy RIPE aut-num object. The RIPE Database web interface can also expose the current object and, where available, its version history RIPE Database lookup.

Those records matter because they define the legal-administrative surface on which a resource is described. A current DFINFRA identifier in an organization, name, entity or remarks field could support an administrative association. A maintainer relationship could show that an account or organization has authority to alter a database object. A recorded change could establish that the administrative state changed at a particular time.

But administrative authority is not equivalent to operational control. A sponsoring local Internet registry member, resource holder, shared maintainer or service provider may be able to edit a record without operating the routers that originate routes under AS210860. Conversely, an operator may use delegated infrastructure while the public registry continues to display another entity. The registry therefore supplies a necessary identity test, not the conclusion.

This distinction also limits the economic reading. A name in an aut-num object does not show that DFINFRA sells connectivity, carries customer traffic, controls address inventory, receives transit revenue or bears the cost of maintaining a network. Those claims require separate corporate, contractual or operational evidence. Without it, the commercial interpretation remains hypothetical.

The subject directory entry is useful as an index to the investigation, not as an independent operating record: DFINFRA directory entry.

Routing authorization is permission, not activity

The second layer concerns the right to originate routes. The RIPE inverse-origin search can identify route and route6 objects whose origin attribute is AS210860, along with prefixes, maintainers and timestamps RIPE inverse-origin search. RADb can broaden the search across routing registries and expose route, route6, aut-num and policy objects RADb query.

A matching route object is evidence of an administrative routing assertion. It can indicate that a prefix was intended or authorized to be originated by AS210860 in the relevant registry. It does not prove that the prefix was announced at the time of observation. It also does not prove that the maintainer of the object controlled the BGP session, or that DFINFRA itself performed the underlying operational work.

RPKI adds a cryptographic authorization layer, but it answers a different question. The Cloudflare RPKI explorer can identify validated ROA payloads authorizing AS210860 to originate specified prefixes subject to maximum-length constraints Cloudflare RPKI explorer. A matching ROA would show that the relevant certificate or delegated resource holder authorized AS210860 as an origin. It would not show that a route was currently announced, that a BGP session existed, or that DFINFRA controlled the router.

The separation is important in both directions. Authorization can exist while no route is visible. A route can be visible while the relevant authorization is absent, invalid or not found in the inspected system. An IRR object and a ROA can be maintained by a resource holder, sponsor or automation service rather than by the organization operating AS210860. Treating either as a proxy for control would collapse permission, intention and execution into one unsupported claim.

BGP can show operation, but not the operator’s name

The third layer is observed routing behavior. RIPEstat’s AS overview can combine registry-derived information with an indication of whether AS210860 is observed as announced RIPEstat AS overview. Its announced-prefixes endpoint can identify IPv4 and IPv6 prefixes observed by RIPE RIS with AS210860 as the BGP origin RIPEstat announced prefixes. The routing-status endpoint can report observed routed address space and visibility information RIPEstat routing status.

These observations are operationally stronger than a registry label. If a prefix is repeatedly visible from multiple collectors with AS210860 as origin, some actor is maintaining route origination under that ASN. If the route disappears and later returns, the sequence may show that someone controlling the relevant session or acting through an upstream can change routing state. But the observation still identifies an ASN, not a corporate decision-maker.

The BGP-updates endpoint is designed to expose announcements, withdrawals and path changes over a selected interval RIPEstat BGP updates. The BGPlay timeline can visualize those events and compare them with other changes RIPEstat BGPlay. Such evidence could support a time-bounded operating finding. It could show that routing changed, when it changed and which paths were visible to the collectors.

It would not, without more, show who ordered the change. Collector resets, peer-session churn, upstream behavior, best-path selection and ordinary routing instability can produce updates without an intentional action by AS210860. RIPE RIS observes only part of the global routing system. A short period without an update does not show that the ASN cannot be activated; it may simply have been stable.

The appropriate test is therefore attribution, not mere activity. A strong case would align a current identity record, authorization state, observed route behavior and an independently documented capability to initiate, maintain, alter or withdraw that behavior. The timestamps would need to be compared, and the alternative explanation—delegation to a transit or managed-network provider—would need to be addressed.

Connectivity clues are not customer contracts

Observed neighbors can help identify the network position around AS210860. RIPEstat’s ASN-neighbours endpoint can identify ASNs seen adjacent to AS210860 in RIPE RIS paths RIPEstat ASN neighbours. Repeated adjacency may identify candidate transit providers, customers, route servers or peers, although path structure does not by itself establish the commercial direction of the relationship.

PeeringDB supplies a different type of signal. Its network record may contain a self-published name, website, policy, contacts, facilities and exchange participation PeeringDB network record. A profile linking AS210860 to a DFINFRA-controlled website or contact domain would be useful self-attribution evidence. An exchange or facility listing, however, indicates claimed or intended presence rather than proof of a live BGP session or route origination.

Independent route summaries can provide another comparison point. The bgp.tools page for AS210860 may summarize originated prefixes, upstreams, peers, visibility, IRR coverage and RPKI status bgp.tools AS210860. Hurricane Electric’s BGP page offers a separate view of routing observations and network relationships BGP HE AS210860. Agreement across services would improve confidence in the observation; disagreement would require investigation rather than selection of the most convenient result.

None of these sources is a substitute for commercial evidence. A visible upstream does not reveal the contract, payment flow or customer obligation behind it. A peering listing does not establish revenue. A route’s global visibility does not show whether the ASN supports a material service, a test network, a delegated function or an inactive corporate label. To translate network position into market power, the investigation would need evidence of customers, capacity, service commitments, pricing, traffic dependence or a credible cost of substitution.

The control chain and its failure points

The control chain can be represented as five linked propositions.

First, DFINFRA must be connected to a current identity associated with AS210860. This is the registry proposition. Second, the same identity or an authorized delegate must be connected to the relevant route objects, ROAs or maintenance rights. This is the authorization proposition. Third, AS210860 must be observed originating or changing routes in a defined time window. This is the operational proposition. Fourth, a person or organization must be identifiable as capable of initiating, maintaining, altering or reversing the observed action. This is the attribution proposition.

Fifth, the resource must sit inside a service or transaction whose disruption, continuation or expansion has a measurable economic effect. This is the market proposition.

The chain fails if any link is assumed rather than evidenced. A registry match without route activity is an identity signal. Route activity without identity attribution is an ASN-level operating signal. Identity and activity without customer or financial evidence is not yet market power. Conversely, a delegated operating model may mean DFINFRA has meaningful commercial control while another company has technical control. The two forms of control should not be conflated.

This is where the present evidence stops. The source package identifies the endpoints that could test every link, but the current field values were not retrieved and compared in this run. It therefore cannot establish a current DFINFRA holder label, a count or list of originated prefixes, a current ROA state, a verified BGP event sequence, a stable neighbor set, a PeeringDB self-attribution or a contractual relationship with a transit provider or customer.

That limitation is narrower—and more useful—than saying the public record proves nothing. The research has identified a falsifiable next step. Retrieve the current records at a common timestamp; compare the administrative identity with route and authorization maintainers; select a defined BGP interval; test whether announcements, withdrawals or path changes occurred; then investigate whether a documented DFINFRA action coincided with the change. If the evidence instead points to a sponsor, upstream or managed operator, the conclusion should shift accordingly.

What would matter economically

The operating question matters because route control can create a capability to affect reachability. An organization able to originate and withdraw routes may influence whether a prefix is visible, which upstream paths are available and how quickly a service can recover from a routing failure. That capability can matter to customers and counterparties if the ASN carries production traffic or anchors scarce connectivity.

But capability is not automatically power. Market power depends on alternatives, switching costs, contractual commitments and the cost of failure. If DFINFRA controls only a registry relationship while an independent operator controls the routers, the operational risk sits elsewhere. If a transit provider can change the route without DFINFRA’s direct intervention, DFINFRA may retain a commercial relationship but not unilateral technical control. If AS210860 is lightly used or easily replaced, even confirmed control may have limited economic significance.

The reverse is also possible. A managed-network arrangement could leave DFINFRA without direct router access while still giving it contractual authority over service design, customer commitments or payment flows. That would be a different control thesis and would require different evidence. The correct investigation cannot infer it from BGP alone.

The next observable condition is therefore not simply “a route appears.” It is a documented, time-correlated change that can be tied to a responsible actor and then connected to a service consequence: a reachability change, a customer-impacting event, a capacity decision, a pricing exposure or a recoverability constraint. Without that final connection, the article should resist converting technical visibility into a valuation or dependency claim.

Bounded conclusion

The current public evidence supports an investigation into DFINFRA and AS210860. It does not support a current conclusion that DFINFRA owns, operates or controls AS210860, nor that the ASN creates identifiable customer dependency, market power or cash-flow exposure for the company.

The important state difference is between a testable control chain and a completed attribution. Public registries, IRR objects, RPKI records, BGP observations, neighbor data and PeeringDB can each illuminate one part of the chain. They do not become proof merely by being placed in the same article. The missing step is an attributable, time-bounded connection between DFINFRA and the ability to cause or reverse an observed network action, followed by evidence that the action matters to a real service or commercial obligation.

That is the condition to watch next. A current record change, a route or authorization change, a correlated BGP event and a named responsible operator would materially advance the case. Until those elements are retrieved and compared, the defensible conclusion remains limited: DFINFRA’s association with AS210860 is a research signal, not established operational control.