Summary

  • Public association between DFINFRA and AS210860 identifies an investigation, not proof of ownership, operation or commercial control.
  • A defensible conclusion requires separately time-stamped evidence for registry identity, object-maintenance authority, IRR assertions, observed BGP activity, RPKI authorization, physical operation and economic decision rights.

The central finding is deliberately bounded. The available material defines a reproducible test for DFINFRA’s operational significance, but this research run did not retrieve the current contents of the public endpoints needed to execute that test. No present routing, RPKI, peering, legal-entity or commercial result should therefore be presented as verified.

That limitation does not make the investigation empty. It changes what can responsibly be claimed. Instead of repeating that a registry name is not the same thing as network control, the evidence can be organized into a control-chain audit: a sequence of distinct propositions, each with its own source, time window and falsification condition. The audit shows where the public record could establish a power to alter network state, where it could establish only a published assertion, and where a technical association would still stop short of a commercial conclusion.

The question left by prior coverage

Earlier coverage established the important negative proposition: DFINFRA’s public association with AS210860 does not, by itself, prove that DFINFRA owns the network, operates routers, controls route announcements or receives revenue from services associated with the ASN. That distinction is necessary, but it leaves a more useful question open.

Can the association be connected, within a defined time window, to one identifiable actor that appears across several independently controlled layers? The relevant layers include the RIPE aut-num record, related organisation and role objects, route and route6 objects, observed BGP announcements, RPKI authorizations, upstream or peering evidence, physical infrastructure and corporate or customer records.

The test is not whether every layer carries the same name. Delegation, outsourcing, address leasing and managed network services can divide responsibilities. The test is whether the relationships between the layers can be explained, attributed and dated. If one actor is consistently linked to the ability to publish a route assertion, authorize an origin, originate routes, maintain connectivity and make commercial decisions, the control thesis becomes stronger. If those powers divide among different actors, the correct conclusion may be shared, delegated or unresolved control rather than sole control.

A registry record is a ledger assertion

The RIPE aut-num object for AS210860 is the natural starting point. It can identify the published autonomous-system name, linked organisation, contacts, maintainers, routing policy and object timestamps. A database record can therefore establish what the registry published at a particular moment. It can also show whether the public identity or the object’s maintenance relationships changed over time. RIPE NCC aut-num record

It cannot, standing alone, establish the legal identity of every person using the name, ownership of routers, access to a facility, control of an upstream contract or receipt of customer payments. A name in a registry is evidence about a public ledger, not self-proving evidence about all of the assets and decisions that may sit behind it.

The same caution applies to a database search for DFINFRA. A search can reveal appearances in organisation, role, person, maintainer, address or route objects. Repeated contact details, handles, addresses or domains may create a promising identity link. But a text match can refer to a historical record, an unrelated organisation, a registry agent or an outsourced administrator. Each returned object needs to be inspected individually and compared with identifiers that are more specific than a shared string. RIPE Database search for DFINFRA

This is the first control distinction: naming power is not operating power. The ability to associate a public record with an actor may matter because it shapes how outsiders interpret the network. It does not show who can log into a router, order transit, approve a renewal or withdraw a route.

Maintenance authority is narrower than control

The next layer concerns the people or organisations authorized to modify database objects. An inverse-origin search can identify route or route6 objects that publish AS210860 as the intended origin and can expose their maintenance attributes. Those attributes matter because they can identify who is permitted to alter a particular registry assertion. RIPE inverse-origin search for AS210860

That is useful evidence, but it answers a narrow question: who can change this database object? It does not automatically answer who controls the address space, configures the routers, occupies the facility or receives revenue. RIPE’s documentation describes authorization for creating and modifying route objects; it does not turn a maintainer relationship into proof of physical or commercial control. RIPE route-object authorization documentation

A maintainer may be an operator, but may also be an internet service provider, sponsoring organisation, consultant, registry intermediary or other delegated administrator. The relevant investigation therefore needs one row for each object, identifying the object handle, prefix, origin, source, maintainer, creation or modification time and the proposition that the record can support. It should also state what the same row cannot support.

This separation prevents a common analytical error. If DFINFRA appears in an organisation field and a related maintainer can update a route object, that may demonstrate a relationship between identity and database authority. It still does not prove that DFINFRA has the credentials to originate the route, that it owns the prefix, or that it controls the commercial service carried by the route.

IRR objects express intent, not activity

An IRR route object is best understood as a published assertion about an intended origin. It can say that a prefix is registered with AS210860 as its origin and can identify the party able to maintain that assertion. It may be stale, may exist without a live announcement and is not cryptographic proof that the stated origin is authorized to use the prefix.

That makes the comparison with routing observations essential. A route object without a corresponding BGP observation supports a database-level claim, not an active-network claim. Conversely, a BGP route without a matching RIPE route object may reflect another registry source, an incomplete database record or an event that requires further investigation. Neither layer should silently substitute for the other.

The time dimension matters as much as the object type. A route object modified after an observed announcement may be part of a later administrative response rather than evidence of the original operating decision. A long-lived route object with no observed announcement may be a preserved historical assertion. Without creation and change dates aligned to the routing window, the apparent sequence remains ambiguous.

The strongest use of IRR data is therefore comparative. It can test whether the declared origin, maintainer and prefix agree with the routes seen by independent collectors. It can identify contradictions, such as an active route with no corresponding assertion, or a route assertion whose origin is not seen. Those contradictions are not conclusions about wrongdoing or ownership. They are signals that delegation, staleness, incomplete visibility or a different authorization path must be examined.

BGP shows observed propagation, not the whole business

RIPEstat and independent routing aggregators can provide the next layer: observed announcements, originated prefixes, routing status, routing history and neighbouring autonomous systems. These sources are valuable because they examine network behaviour rather than only static database content. RIPEstat ASN overview RIPEstat announced prefixes RIPEstat routing status

But BGP evidence must remain bounded by observer, prefix and time. An observation can support a statement that a collector saw AS210860 originating a particular route during a specified window. It does not prove universal reachability, physical location, legal ownership or commercial control. Collector coverage is incomplete, and a route may be accepted through an upstream configuration, a route server, a leak or another arrangement that is not visible from the observation alone.

The needed record is more precise than “AS210860 is active.” It should list each observed prefix, origin, first and last seen time, withdrawals, AS paths, collector coverage and agreement across independent views. Routing history can show persistence or recurrence, but it too depends on the coverage and retention of the underlying collectors. RIPEstat routing history

Neighbour data can show networks that appear next to AS210860 in observed paths. It cannot by itself distinguish paid transit from settlement-free peering, a customer relationship, a route-server path or temporary leakage. An inferred upstream list is similarly useful as a lead, not as a contract record. RIPEstat ASN neighbours BGPView upstream data

Independent aggregators can help test whether a result is collector-specific. Profiles from bgp.tools, Hurricane Electric, CAIDA or Cloudflare may offer different views of prefixes, peers, history or inferred relationships. Agreement would increase confidence in an observation; it would not convert an inferred relationship into proof of a paid contract or identify DFINFRA as the responsible company. bgp.tools AS210860 profile Hurricane Electric BGP Toolkit CAIDA AS Rank Cloudflare Radar AS210860 profile IPinfo AS210860 profile

The practical consequence is that routing activity and network control should be written as separate propositions. “A route was observed” is a technical observation. “DFINFRA controlled the routers that originated it” is an attribution claim. “DFINFRA sold capacity or collected revenue from it” is an economic claim. Each requires an additional bridge.

RPKI answers an authorization question

RPKI adds a cryptographic authorization layer, but not the missing corporate conclusion. A validated ROA can authorize an ASN to originate a specified prefix up to a specified maximum length. Comparing a contemporaneous VRP set with an observed prefix, origin and length tuple can classify the relationship as authorized, unauthorized or not covered by a VRP. Cloudflare RPKI repository RFC 6482

The distinction is fundamental. A VRP without an observed route supports authorization without observed operation. A route without a matching VRP may still be observed activity, but it must not be described as positively RPKI-authorized from that dataset. A ROA does not identify the person configuring the router, the company paying for transit or the owner of a customer-facing service.

RPKI evidence must also be time-aligned. The relevant VRP set, retrieval time, validation configuration, prefix and maximum length should be preserved alongside the BGP observation. A later VRP cannot be used casually to explain an earlier route, and an absence from one relying-party export does not necessarily prove that no authorization existed elsewhere or that a route was illegitimate.

This layer therefore narrows uncertainty without eliminating it. If the same observed route is repeatedly aligned with a matching VRP and the relevant registry and infrastructure evidence points to one operator, the operational thesis becomes stronger. If the route is observed but authorization points to a different resource holder, the article should consider delegation, leasing or an unresolved conflict before assigning control to DFINFRA.

Physical operation needs a different kind of evidence

A functioning ASN can be connected to physical facilities, equipment administration, cross-connects, upstream delivery and service infrastructure. Those indicators are closer to operating capability than a registry label, but they also require attribution.

PeeringDB could provide an operator-supplied network name, website, network type, policy, facilities, exchanges and contact information. A record explicitly tying DFINFRA to AS210860 would be a stronger self-presentation than an incidental name match. It would still be self-reported and could be outdated or incomplete. Facilities and exchanges show potential points of presence, not necessarily ownership of equipment or the commercial terms of connectivity. PeeringDB network record for ASN 210860

Internet-scan data may identify hosts, services, certificates or domains in address space attributed to AS210860. Such observations can generate leads about customer-facing infrastructure or a company-controlled domain. They cannot, without corroboration, distinguish an operator from a tenant, reseller, proxy or hosted customer. Censys host search for AS210860

The same principle applies to third-party ASN profiles and hosted-domain databases. They may reveal a service footprint, but attribution must be tested using timestamps, ownership identifiers, support contacts, certificates, facility records and other independently controlled evidence. The absence of a public profile would not prove the absence of physical operation; the presence of a profile would not prove DFINFRA’s sole control.

Commercial control is an economic proposition

The most consequential leap would be from technical association to commercial significance. That leap cannot be made through an ASN, a route object or a neighbour graph alone.

Commercial control concerns decision rights and economic flows: who contracts with customers, sets prices, approves renewals, receives payment, supplies support, orders transit, bears continuity obligations or controls the operating company. Useful evidence could include primary corporate filings, an operator-controlled website, customer terms, invoices, payment recipients, support communications, facility or transit documentation and records that connect the legal entity to the technical identifiers.

An OpenCorporates search may identify candidate legal entities, jurisdictions, officers or addresses. Name similarity is not enough. A match needs identifiers that can be compared with the registry record or operating material, and the underlying national filing should be preferred where available. A legal-entity match would establish corporate identity, not automatically operation of AS210860. OpenCorporates DFINFRA search

The public research package contains no independently verified legal-entity match, contract, invoice, customer record or quantified revenue effect. That absence must be described accurately: the evidence was not verified in this run. It is not evidence that no commercial relationship exists. Private arrangements may not appear in technical data or public filings.

Market impact requires a baseline

Even proven operation would not automatically establish market power. A market-impact claim needs a defined market and measurable scale. Relevant measures might include routed address volume, duration of service, number and dependence of customers, traffic, capacity, revenue, price, concentration, substitution options and the continuity effect of a failure.

A small ASN can be operationally real without being economically material. Conversely, a technically modest network could matter to a particular customer or region if alternatives are limited. The counterfactual must be stated: what would customers lose, how quickly could they substitute, and what measurable change would occur if the service disappeared or changed price?

This is where the causal chain often breaks. Observed BGP activity can show propagation. It does not show that customers depended on DFINFRA, that DFINFRA could raise prices, or that a withdrawal would affect a defined market. Those conclusions require customer, traffic, capacity or financial evidence and a plausible alternative comparison.

What would confirm or weaken the thesis?

A future time-stamped evidence set would materially strengthen the operational thesis if the same identifiable operator were linked across the AS210860 aut-num and related registry objects, relevant maintainer relationships, observed BGP announcements, matching IRR and/or RPKI authorization, persistent connectivity and an operator-controlled service or primary corporate record.

The chain would be especially persuasive if the observations were independently collected, aligned to the same time window and supported by evidence of facility, equipment or upstream operation. It would still require a separate commercial bridge before supporting claims about customers, pricing or cash flow.

The thesis would weaken if an adequately documented observation window showed no AS210860 origination, stale or mismatched route objects, unrelated maintainer and operator identities, or infrastructure and commercial records pointing to another actor. None of those findings would automatically disprove every possible relationship. They would narrow the supported proposition and make delegation, historical association or stale data more plausible.

A useful falsification table would therefore ask:

  • If an IRR route object exists but multi-observer BGP checks show no corresponding origination, is the evidence limited to a database assertion?
  • If BGP activity exists but no contemporaneous VRP authorizes the observed tuple, can activity be separated from authorization?
  • If a VRP exists but no route is observed, is the evidence authorization without operation?
  • If registry identity aligns but upstream, facility or service evidence points elsewhere, is the network delegated or outsourced?
  • If routing and RPKI align but contracts, customers and payment flows remain absent, what exactly has been proven?
  • If an exact-name company search fails, have aliases, jurisdictions and historical names been tested?

These questions turn the investigation from an identity dispute into a reproducible test of control.

The bounded conclusion

At the research cutoff, the public material supports a control-chain agenda rather than a verified finding of current control. DFINFRA’s relationship to AS210860 should be examined through separate evidence for registry identity, database maintenance, route assertions, observed origination, RPKI authorization, physical operation and commercial decision rights.

The strongest defensible conclusion is that the chain has been defined but not executed with live, time-stamped endpoint results. DFINFRA’s current ownership, operation, authorization, physical role, commercial control and market effect concerning AS210860 remain unverified—not established and not disproved.

That is a more useful result than another repetition of the registry warning. It identifies the precise next observation that could change the assessment: repeated, multi-observer routing evidence for identified prefixes, aligned with relevant registry and authorization records, connected to an independently attributable operating service and, if economic significance is claimed, to measurable customers, decisions or cash flows. Until that bridge is built, the responsible boundary is clear. A name beside an ASN is a lead. Control is a chain.