Summary

  • Public RIPE records can associate the DFINFRA label with AS210860 and distinguish administrative registration from observed routing, but they do not establish legal ownership, physical deployment or customer service.
  • Route objects, RPKI authorization, AS-path adjacency and measurement records answer different questions. None alone proves that DFINFRA can operate, restore or commercially monetize the network.

DFINFRA’s public association with AS210860 is a useful starting point because it is specific enough to test. The RIPE Database provides an administrative record for the autonomous system, while RIPEstat and other routing services provide observations of what collectors have seen. Those are not interchangeable forms of evidence. A registration can persist when no route is visible. A route can be visible when the registered name does not identify the party operating the equipment. An RPKI authorization can permit an origin without proving that the origin is currently announcing the prefix or delivering a service.

The distinction matters because previous public coverage has already established the central gap: DFINFRA appears alongside AS210860 in internet-resource records, but the available material does not close the chain from registration to operational control. This investigation tests what can be added without pretending that a directory label is a corporate ownership record or that a BGP observation is a service-level measurement.

Five different questions hidden inside one ASN

The first question is administrative: what does the registry say about AS210860, and which names, contacts, maintainers or organizations are attached to that record? RIPE’s RDAP service is the primary standardized source for the assignment record, while the native RIPE Database object exposes attributes that may include an as-name, linked organization, contacts, maintainers, routing policy and event dates. Those fields can establish a public administrative association. They do not automatically identify a beneficial owner or the person with authority over deployed equipment. RIPE RDAP RIPE aut-num object

The second question is resource authority: which address blocks are connected to AS210860, and who is entitled to originate them? A search for DFINFRA can reveal whether the name is linked through an organization object or appears only as text in an unrelated record. Inverse searches for route and route6 objects can show that the RIPE Internet Routing Registry contains declared origin relationships. Such objects are administrative routing-policy statements. They are not cryptographic authorization, and they are not proof that a route is live. DFINFRA RIPE search IPv4 route objects IPv6 route6 objects

The third question is observable operation: has AS210860 been visible in routing data, when, and with which prefixes? RIPEstat’s AS overview, announced-prefixes, routing-history, first-and-last-seen and routing-status endpoints can provide a time-bounded view from RIPE RIS collectors. BGP.Tools and Hurricane Electric offer independent public views that can be compared with RIPE’s observations. A positive observation supports the narrower statement that a collector saw routing information associated with AS210860 at a particular time. It does not establish universal reachability, traffic volume or the identity of the person making the announcement. RIPEstat AS overview RIPEstat announced prefixes RIPEstat routing history RIPEstat first and last seen RIPEstat routing status BGP.Tools Hurricane Electric BGP

The fourth question is authorization and security: does a current validated RPKI payload authorize AS210860 to originate each observed prefix, at the observed prefix length? That requires checking every prefix against the current ROA data, including maximum-length constraints. A valid ROA means that the cryptographic authorization is consistent with the stated origin for the covered space. It does not prove that the route is announced, that the address holder operates the network, or that an application or customer service is reachable. The RPKI dataset is therefore one layer in the control test, not the test’s conclusion. Cloudflare RPKI payload

The fifth question is consequential control: what changes when AS210860 changes? Can an identifiable actor create, maintain, alter or withdraw routes? Can that capability be connected to a physical network, an upstream or peer relationship, a customer service, a continuity obligation or an economic consequence? Public AS-path adjacency can support the existence of observed connectivity, but it cannot distinguish paid transit from settlement-free peering or prove a contract, capacity, uptime or bargaining relationship. PeeringDB can provide contextual information about a network record, but it does not turn an adjacency into a commercial agreement. RIPEstat AS neighbours PeeringDB network record

What the current records can establish

The strongest defensible claim is layered rather than absolute. RIPE’s registry records provide a public administrative object for AS210860 and a route through which the DFINFRA name can be investigated. Routing services can then test whether the ASN has been observed as an origin and which prefixes were visible to particular collectors. Historical endpoints can separate earlier visibility from present visibility. These are meaningful facts because they define a reproducible observation path.

The evidence should be reported with its time boundary. Mutable registry and routing responses are not timeless documents. A current AS overview can change after the next routing update. A prefix can disappear from one collector and remain visible to another. A last-seen value records what a particular observation system saw, not the last instant at which a network existed anywhere. For that reason, a claim that AS210860 is active should identify the source, the data time and the collector limitation rather than restating a registry association as a present-tense operational fact.

The RIPE Database’s declared import and export policy must also be treated as a declaration. It can describe intended routing relationships, but it does not prove that the sessions exist, that the policy is current or that the corresponding paths are actually used. Similarly, a route object indicates an administrative origin relationship in the queried registry view. It can survive after a route is withdrawn, and it can disagree with RPKI or live BGP observations. The disagreement is not a technical nuisance; it is evidence that the layers answer different questions.

A useful investigation therefore keeps four records separate: the identity record, the authorization record, the observation record and the consequence record. The identity record says who is named in a registry. The authorization record says what a maintainer, route object or ROA declares or permits. The observation record says what collectors or measurement systems saw. The consequence record says whether an identifiable service, customer, facility or economic process was affected. Only the last category can support a claim about practical dependency, and it requires evidence beyond an ASN page.

What the records do not establish

Nothing in the current public evidence proves that DFINFRA is the legal beneficial owner of AS210860. A registry organization, sponsoring Internet registry, maintainer, administrative contact and technical contact may be different parties. A trading name may not match a legal entity. If the article were to identify ultimate authority over DFINFRA, it would need a corporate or legal source rather than relying on the RIPE label alone.

The evidence also does not prove physical deployment. An ASN can be registered without a currently visible route. A visible route does not disclose whether the announcing equipment is in a data centre, on a leased platform, behind an outsourced network operator or in another arrangement. RIPE Atlas probe searches can indicate whether probes are associated with an ASN in the relevant API view, but a probe or measurement vantage point is not proof of customer use, traffic volume, facility presence or service uptime. RIPE Atlas IPv4 probe search RIPE Atlas IPv6 probe search

Nor does route visibility prove resilience. A route can be visible while an application is unavailable. An outage can affect only one prefix or one geography. A withdrawn route can be restored by an upstream, a provider or a party other than the named registry organization. To prove continuity, an investigation would need a common timeline combining route loss, independent reachability failure, path change or failover, restoration and an attributable operator action. The current package does not contain that completed sequence.

The same caution applies to commercial value. AS-path adjacency is not a price sheet. PeeringDB metadata does not prove paid transit, settlement-free peering, session uptime, capacity or contract duration. A route announcement does not prove that customers use the address space, that traffic crosses the ASN at material volume or that DFINFRA captures revenue from the resource. The absence of those facts is not evidence that no service exists; it is a boundary on what can be responsibly claimed from the available sources.

The operational-control test

The control question can be expressed as a chain of observable events:

  1. A registry identifies an administrative relationship involving DFINFRA and AS210860.
  2. A named party has the authority to maintain relevant registry or routing objects.
  3. One or more prefixes are observed as originated by AS210860 at a specified time.
  4. RPKI and, where relevant, IRR records are checked against each observed prefix and prefix length.
  5. Independent collectors or measurement systems corroborate the routing state.
  6. The same identifiable actor can be linked to the ability to change, withdraw or restore the route.
  7. A service, customer, facility or economic consequence is documented in the same time window.

The first five steps can be approached with public machine-readable sources. The last two generally require operator records, service-layer measurements, contractual material, incident reporting or a carefully designed active measurement campaign. The current evidence reaches the beginning of this chain and clarifies its missing links. It does not justify skipping from step one to step seven.

That framework also explains why a negative result must be stated precisely. The research did not show that DFINFRA has no operational role. It showed that the available public records do not attribute a complete operating capability to DFINFRA. The distinction protects against two opposite errors: treating an administrative name as proof of control, and treating an incomplete public record as proof that no network activity exists.

Why the distinction matters to network operators

For operators, the practical risk is not the label attached to an ASN. It is uncertainty about who can change the state on which a dependency rests. If a service relies on a prefix, a route origin, an upstream relationship or an address resource, the important questions are who can authorize change, how quickly a change is detected, what alternate path exists and which party is responsible for restoration.

A registry record can help an operator find the relevant party, but it cannot substitute for an escalation path. An RPKI-valid route can reduce one class of origin risk, but it does not guarantee availability. A stable AS path can show connectivity from a collector’s perspective, but it does not prove contractual continuity. Operational assurance requires evidence that connects the control plane to a service plane.

This is also why the current absence of a documented failure consequence is material. Without a recorded incident, there is no basis for assigning a recovery obligation or estimating customer exposure. A route history can reveal periods of visibility and withdrawal, but a business-impact claim needs an independent record of what users or services experienced. The research package identifies those gaps rather than filling them with inference.

The next evidence that would change the conclusion

The most valuable next step is a synchronized capture. RIPEstat, BGP.Tools and Hurricane Electric should be queried at a common UTC time, with raw responses, timestamps and hashes retained. The exact currently observed prefix set should then be checked against RIR allocation records, IRR route objects and validated RPKI payloads. Each result should preserve the prefix length and the relevant maximum-length rule.

A second step would identify the administrative path more carefully. Every RIPE object matching DFINFRA should be inspected individually to distinguish a directly linked organization from a text occurrence, a historical remark or a third-party contact. Maintainer and organization relationships should not be collapsed into legal ownership.

A third step would test consequence rather than merely visibility. Independent probes could monitor reachability to selected announced prefixes, while route collectors track path changes. If a future withdrawal or restoration occurs, the investigation could ask who announced the change, who restored it and whether any independently documented service was affected. That would move the article from a control-chain hypothesis toward an attributable operational finding.

The RIPE delegated statistics file can provide allocation context, but it cannot prove who operates a network on a particular day. RIPE delegated statistics The Potaroo AS report and NLNOG IRR Explorer can provide comparison points, but each remains bounded by its data source and observation method. Potaroo AS report NLNOG IRR Explorer

Conclusion

DFINFRA’s association with AS210860 is neither meaningless nor sufficient. It is a public signal that supports a disciplined investigation into identity, authorization and routing visibility. The available evidence can distinguish an administrative record from a collector observation, a route object from an RPKI authorization and an AS-path adjacency from a commercial relationship.

What it cannot yet do is identify, with a time-bounded and independently corroborated chain, the party that operates the network, controls its recovery or captures value from a service. That is the operational boundary. Until the evidence connects registry identity to attributable change capability and then to a documented consequence, the responsible conclusion is narrower: AS210860 is observable as a network-resource object associated with DFINFRA in public records, while durable operational control remains unproven.