Summary

  • Public records define a credible investigation path from DFINFRA and AS210860 to routing activity, authorization state and interconnection evidence, but the current package does not establish that DFINFRA owns, operates or controls the autonomous system.
  • Registry records, IRR objects, RPKI authorization, BGP visibility and measurement data answer different questions. None, standing alone, identifies the person or organization able to approve, execute or reverse a network change.

The important question about DFINFRA is no longer whether its name appears in a public Internet-number record. Earlier coverage established that it does. The more consequential question is whether independent evidence can connect that identity to a working operating surface: routes that are actually originated, resources that are authorized, relationships that are visible from outside, and a person or institution with the ability to change those conditions.

The current evidence package does not close that chain. It maps the sources needed to test it and records why each layer must be kept separate.

Five layers, five different questions

The first layer is registry identity. RIPE Database aut-num records, RDAP responses and historical Whois data can show how AS210860 is represented in administrative systems. An aut-num object can contain an autonomous-system name, organization references, contacts, routing-policy attributes and maintainer fields. An RDAP response can corroborate the registration and event structure for the number resource. Historical records can reveal changes to those fields.

Those are useful facts about the registry. They are not proof that the named organization operates production routers, controls a customer relationship or can change an announcement. Administrative authority over a database object and operational authority over a network may coincide, but the first does not prove the second. The current aut-num endpoint is the relevant public record for that distinction: RIPE Database aut-num record for AS210860. The corresponding RIPE RDAP record provides a separate registration view.

The second layer is IRR declaration. A route or route6 object whose origin is AS210860 would show that a routing intention has been recorded in an Internet Routing Registry. The inverse-origin query is designed to find such objects: RIPE Database inverse origin search for AS210860. A maintainer field would show which database accounts are authorized to modify the object.

That remains a declaration in a registry. A route object is not an observed announcement, and it is not an RPKI certificate. It can be stale, incomplete or absent even while a route is visible elsewhere. Conversely, a registered object can persist after an announcement has disappeared. The useful test is therefore not whether an IRR object exists, but whether its prefix, origin and maintainer history align with independently observed routing at a documented time.

The third layer is RPKI. A Route Origin Authorization can state that AS210860 is authorized to originate a particular prefix up to a maximum length. A validator can classify a matching route as valid, invalid or not found at the time it evaluates the relevant data. The Cloudflare RPKI validated payload is a candidate source for filtering authorizations associated with AS210860.

RPKI strengthens the security of an origin claim, but it does not answer the identity question by itself. A valid authorization says that the origin ASN is permitted to originate the matching resource. It does not show who operates the router, who holds the legal relationship behind the ASN, or who can revoke or replace the authorization. RPKI is evidence of authorization, not a title deed and not a personnel record.

The fourth layer is observed BGP behavior. RIPEstat provides endpoints for announced prefixes, routing status, routing history, BGP updates, looking-glass paths, ASN neighbors and routing consistency. These sources can establish whether collectors observed AS210860 originating routes during a defined interval, which prefixes appeared, whether visibility changed, and which AS paths were seen. The relevant endpoints include announced prefixes, routing status, routing history, BGP updates, looking glass, ASN neighbors and routing consistency.

A route observed by multiple collectors is stronger evidence of active origin behavior than an unused registration. It can support a time-bounded statement such as: a collector observed a prefix with AS210860 as origin at a specified time. It cannot support the stronger statement that DFINFRA owns the network or controls the next announcement. BGP exposes propagation and path behavior; it does not expose the person who approved a configuration change.

The fifth layer is external measurement and self-reported interconnection. bgp.tools and the Hurricane Electric BGP Toolkit can provide independent routing views. PeeringDB may contain an operator-submitted network profile, facilities, exchange points, contact roles and peering policy. CAIDA AS Rank can provide inferred relationship context, while RIPE Atlas IPv4 and RIPE Atlas IPv6 are candidate measurement views.

These sources can help distinguish a live interconnection footprint from a name that exists only in administrative data. But each has a boundary. PeeringDB is self-reported. CAIDA relationships are inferred. Atlas visibility depends on measurement placement. BGP tools use their own collector coverage and processing rules. A listed neighbor is not automatically a transit contract, a facility is not automatically an active customer deployment, and a route path is not a legal or commercial agreement.

What the current package actually establishes

The research package identifies 18 public sources across those five layers. It does not contain live-fetched dynamic responses from them. The source set also includes the RIPE historical Whois endpoint, which can be used to compare administrative changes over time. Exact current prefixes, prefix counts, RPKI states, maintainers, route objects, adjacent ASNs, facilities, exchange points and change dates therefore remain unverified in this investigation.

That limitation is not a minor footnote. It prevents a claim that AS210860 is currently announcing a particular prefix, that a particular route is RPKI-valid, or that a named party is the current maintainer. It also prevents a claim that DFINFRA is an active operator merely because the evidence package contains the URLs that could test that proposition.

The distinction is especially important when the subject is a relatively obscure network identity. A public record can be authoritative about what the record says while being silent about who exercises practical control. The correct language is correspondingly narrow: a name is listed or publicly associated; a route is declared; an origin is authorized or validated at an observed time; a path is observed; an interconnection is self-reported or inferred. The words operates and controls require convergent, actor-attributable evidence.

The missing element is not another generic lookup. It is a causal link. A useful investigation would need a documented baseline, a material change after that baseline, and evidence connecting DFINFRA to the ability to cause, sustain, alter or reverse the change. That could involve an operator-controlled profile aligned with current BGP observations, a maintainer or authorization change with attributable access, a contemporaneous announcement or withdrawal, and independent records showing who initiated or could undo it. Without that connection, the evidence remains a set of adjacent observations rather than a demonstrated control surface.

Why the operating mechanism matters

Routing control has practical consequences because an announcement can alter reachability. An authorization can permit or constrain which ASN may originate a prefix. A maintainer account can change a registry declaration. An upstream or exchange relationship can affect where traffic enters and exits a network. But these mechanisms do not automatically travel together.

A route can be visible without its legal owner being publicly identifiable. A valid ROA can exist without a current announcement. An IRR object can be present without a matching route in the global table. A PeeringDB profile can describe facilities or policy without proving that the profile is current. The network effect emerges only when the relevant layers converge in time and when an actor can be tied to the change.

This is the difference between infrastructure evidence and infrastructure attribution. Infrastructure evidence can show that a technical condition existed. Infrastructure attribution asks who had the authority and capability to make it exist, persist or disappear. The first is often observable from public measurement. The second may require operator records, authenticated change histories, contracts, filings or a direct response from the named party.

The current package has no legal or contractual evidence establishing ownership. It has no actor-attributable evidence identifying who requested, approved, executed or could reverse a routing or authorization change. Nor does silence, a mismatch between sources or incomplete data justify inferring an alternative controller. The responsible conclusion is bounded: the public sources map the test for operational control, but they do not demonstrate that DFINFRA owns, operates or controls AS210860.

A measurable next step

The investigation can become more decisive without becoming more speculative. First, capture timestamped responses from the RIPEstat announced-prefixes, routing-status, routing-history, BGP-updates and looking-glass endpoints. Record the prefix set, origin observations, collector context and change dates. Second, retrieve the RIPE aut-num, inverse-origin, RDAP and historical Whois records at the same time. Third, compare each observed route with IRR declarations and the RPKI payload, recording the maximum length and validation state rather than collapsing them into one label.

Fourth, compare the result with independent views from bgp.tools and Hurricane Electric. Fifth, inspect PeeringDB, CAIDA and RIPE Atlas for corroborating—but clearly labeled—evidence about interconnection and measurement visibility. The result should identify agreements and disagreements across sources, not hide them behind a single “active” or “inactive” conclusion.

The key event to watch is a material routing or authorization change after that baseline. A prefix addition, withdrawal, origin change, maintainer transfer or ROA modification would be technically meaningful. It would become evidence about DFINFRA only if an independently verifiable record showed that DFINFRA initiated, approved or could reverse the change. The consequence would then be bounded as well: a demonstrated ability to alter reachability or authorization for a defined resource, not an unsupported claim about an entire organization or service business.

Until that event and attribution exist, the public record supports an investigation, not a verdict. The name DFINFRA marks a point where the evidence chain can begin. It does not, on the current record, identify who holds the controls at the end of that chain.