Summary

A failed read as a finding

The starting point of this article is unusual: a negative. The research question posed to the authoritative endpoint was narrow and first-party. Query the RIPE Database web UI lookup for the aut-num AS210860; recover status, organisation, role, contact, maintainer, route and last-modified fields; compare them against the mirrors that September coverage was forced to rely on. The query was made directly against https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num. What came back was not an object. It was a page title — an application shell for a client-rendered JavaScript interface whose registry content is fetched by the browser after page load. No RPSL text, no field values, no timestamps.

That failure matters because of who has reported it and how consistently. The September 2026 DFINFRA coverage conceded, in its own words, that the authoritative RIPE endpoint "returned only an interface shell when queried" and that all registry facts in those articles were therefore mirror-based. This run reproduced the same failure against the same URL. Two investigations, weeks apart, both unable to read the same authoritative document. The conclusion is not that the endpoint is down — the page loads, the title renders — but that its content is structurally unavailable to text-based retrieval. This is not a footnote.

It is a property of the evidence chain that every subsequent claim in this article must carry.

The August 2026 coverage of this same subject handled the gap by writing around it: it stated that live field values had not been retrieved, defined the four evidence layers — recorded, authorized, observed, controlled — and identified the endpoints that would settle the open questions. This article attempts the settling and documents that the settling did not happen. That is a change in the record worth reporting on its own terms: as of the date of this article, the DFINFRA/AS210860 chain still has no first-party witness.

What the mirrors agree on, verbatim

With the authoritative read closed, the registry layer rests on mirrors. Two of them — whois.ipip.net https://whois.ipip.net/AS210860 and IP.CC https://ip.cc/topic/asn/AS210860/ — returned RPSL text that reads as a direct reproduction of RIPE WHOIS output, and their aut-num blocks agree field for field. The mirrored object runs:

aut-num:        AS210860
as-name:        edeka_digital
org:            ORG-EDG14-RIPE
import:         from AS9211 accept ANY
export:         to AS9211 announce AS210860
import:         from AS13237 accept ANY
export:         to AS13237 announce AS210860
admin-c:        DA9499-RIPE
tech-c:         DA9499-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         EDDI-MNT
created:        2021-08-24T08:30:41Z
last-modified:  2021-10-27T08:53:15Z
source:         RIPE

Read carefully, this is a dense statement of registry state. The status attribute reads ASSIGNED — meaning, per RIPE's own documentation, that the resource was assigned by the RIPE NCC https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/. The as-name is edeka_digital, pointing at a German retail and wholesale food group's digital arm rather than anything named DFINFRA. The organisation reference is ORG-EDG14-RIPE. The administrative and technical contact is a single role handle, DA9499-RIPE, whose role name is DFINFRA — the one place in the registry record where the name this coverage follows actually appears. Two maintainers hold authority over the object: RIPE-NCC-END-MNT, the registry's own end-maintainer, and EDDI-MNT, the resource holder's maintainer. And the object has been untouched, according to both mirrors, since 27 October 2021 — created in August 2021, modified once, then stable for roughly five years.

The dual import/export policy declarations name two transit providers: AS9211, a Hamburg-based network operator, and AS13237, AS112 of the European open peering landscape. Both mirrors reproduce both pairs identically. Nothing in the aut-num object itself enumerates prefixes. That is not an omission in the mirrors; it is how the RIPE framework works. RIPE's documentation of primary objects states that the aut-num serves registry and routing-registry purposes together, but that prefixes are not attributes of the aut-num — they bind to the origin through separate route and route6 objects, authorised by the object's maintainers in the absence of a dedicated mnt-routes attribute https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/. This is the interpretive key for the whole case: an aut-num with no visible route objects is not the same thing as a network with no routes, and neither is it the same thing as a network with routes. The route-object layer must be queried separately, and in this run it was not successfully queried anywhere.

Two independent mirrors agreeing on a reproduced object, field for field and timestamp for timestamp, is real corroboration. It is not, and should never be confused with, first-party evidence. A mirror is a copy whose snapshot date is not exposed, whose filtering rules are its own, and whose rendering may lag or diverge from the live database without notice. What the agreement actually proves is that two parties have captured what appears to be the same underlying WHOIS output. What it does not prove is that the output matches the live object today.

Where the mirrors disagree, and why it matters

If the two mirrors agreed on everything, the mirror-only constraint would be less consequential. They do not. The aut-num block agrees; the organisation object they attach to ORG-EDG14-RIPE does not.

The whois.ipip.net mirror renders the organisation as EDEKA Verwaltungs- und Beteiligungs GmbH — a Hamburg holding entity, with a registered number recorded as District court Hamburg HRB 90516, an address at New-York-Ring 6, 22297 Hamburg, org-type LIR, created 2021-06-10T07:41:43Z and last-modified 2026-05-13T07:28:38Z https://whois.ipip.net/AS210860. The IP.CC mirror renders the same handle as EDEKA DIGITAL GmbH, with the same creation timestamp but a last-modified of 2021-10-27T08:58:29Z https://ip.cc/topic/asn/AS210860/. The Hurricane Electric listing and IPinfo both use the Verwaltungs- und Beteiligungs name as the AS holder label, consistent with the ipip.net rendering rather than IP.CC's https://bgp.he.net/AS210860 https://ipinfo.io/AS210860.

Three disagreements follow from this, each with a different evidentiary shape.

The first is the organisation name itself. EDEKA DIGITAL GmbH and EDEKA Verwaltungs- und Beteiligungs GmbH are plausibly related corporate entities — a digital operating name and a holding vehicle — but the record does not say which one the live ORG-EDG14-RIPE object names today, or whether the object was modified to move between them. A name change on a 2026-05-13 modification of the org object is one possible explanation for the divergence; a stale mirror is another; a differently-filtered copy is a third. The retained evidence does not adjudicate among them, and this article will not pretend otherwise.

The second is the freshness of the organisation object. A last-modified of 2026-05-13 means the object changed sometime this year on one mirror's reading; a last-modified of 2021-10-27 means it has been frozen since the same day the aut-num was last touched on the other. These are not cosmetic differences. If the org object genuinely changed in May 2026, that is the only 2026-dated modification anywhere in the registry record for this resource — a single point of recent change in an otherwise five-year-frozen chain. If it did not, the record is entirely a 2021 artefact.

The distinction between a record with one recent touchpoint and a record with none is exactly the kind of difference a monitoring reader needs to know is unresolved.

The third is the as-block context, where the divergence is least explicable. The ipip.net mirror reproduces a containing as-block of AS208189–AS214345, created and last-modified 2026-02-12T14:40:05Z; the ipgeolocation.io raw-whois fragment shows a containing block of AS208885–AS214345, created and last-modified 2026-07-13T14:17:33Z https://whois.ipip.net/AS210860 https://ipgeolocation.io/browse/asn/AS210860. RIPE as-blocks are administrative containers, and both ranges end at the same upper bound, but a 697-number difference in the lower bound and a five-month difference in the stated modification date indicate that at least one of the two renderings is describing something other than the same live block record. This is a low-stakes field — the containing block determines little about the resource — but it is diagnostic: when mirrors diverge even on a container object whose values should be simple, the mirrors' general reliability for this resource has a measured floor below the reader's intuition.

A fourth disagreement sits one layer up, in the aggregator market, and is worth separating from the rest. IPgeolocation.io renders AS210860 as belonging to "RIPE Network Coordination Centre" itself, country NL, with Date Allocated N/A and zero routes https://ipgeolocation.io/browse/asn/AS210860. Naming the RIR as the holder of an assigned resource contradicts both WHOIS mirrors, and the N/A allocation date contradicts the 2021 creation both of them record. The pattern here — the aggregator falling back to the IANA/RIPE NCC parent record when it cannot resolve the assigned holder — looks like low-fidelity aggregation rather than contradictory registry evidence, and this article treats it as such: an unreliability marker on one source, not a third position in a dispute. The discipline the Doctrine lens requires is to keep the contested set visible without letting the weakest participant inflate its size.

The status contradiction, and what documentation actually adjudicates

The sharpest contradiction in the record comes not from a commercial mirror but from a RIPE NCC-operated service. RIPEstat's resource page for AS210860 renders, on panel stamps of 2026-09-14 00:00:00 and 09:03:00, an RIR table row reading RIPE NCC | RESERVED, with no holder name — the page states "Name and holder of this ASN: -" — and zero prefix records https://stat.ripe.net/resource/AS210860. RESERVED, no holder, is a materially different claim from the mirrors' ASSIGNED under a named EDEKA organisation. If RIPEstat's rendering described the live registry state, the resource's whole identity would have changed since 2021: from assigned to reserved, from holder to holderless.

Before treating that as possible, check what the status vocabulary allows. RIPE's first-party documentation of primary objects states that the aut-num status attribute is software-generated from the registry information and can take exactly three values: ASSIGNED, for all AS Numbers assigned by the RIPE NCC; LEGACY; and OTHER, for anything else. A user cannot set, remove or change it; the software sets it on update https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/. RESERVED is not in that vocabulary. Whatever RIPEstat's RESERVED rendering describes, it cannot be describing the live aut-num object's status attribute — because no such value exists for that attribute. The most probable reading, consistent with how RIPEstat draws its registry-overview panel from a different data source than WHOIS, is that the panel reflects a resource-status or registry-information layer whose handling of this particular resource produces a RESERVED rendering — a data-layer difference, not a registry change.

This is an important adjudication, and it is important to state precisely what it adjudicates. The documentation rules out RESERVED as an aut-num status value; it does not prove what the live aut-num status is, because the authoritative endpoint that would show it cannot be read. It also does not fully dissolve the contradiction: RIPEstat is a RIPE NCC service, its panel carries a dated snapshot, and a reader is entitled to ask why a first-party-adjacent rendering of this resource shows no holder while third-party copies of WHOIS output show one.

The correct editorial posture is to report the contradiction with the documentation-based reasoning that partially explains it — and to keep the residual question open, because the only thing that would fully close it is a readable first-party record, which this run again could not obtain.

The routing layer: consensus on silence

If the registry layer is mirror-constrained, the routing layer is the opposite: multiple independent observers, each with its own measurement infrastructure, converge on the same picture, and the picture is silence.

Hurricane Electric's BGP toolkit reports that AS210860 has not been visible in the global routing table since 26 March 2026, with zero currently announced prefixes in both the all-families and IPv4 views, zero RPKI-originated valid and zero RPKI-originated invalid entries, one historically originated IPv4 prefix — 193.21.248.0/21, attributed to EDEKA DIGITAL GmbH — and a single observed peer, AS9211, the Hamburg network operator named in the aut-num's first import/export pair https://bgp.he.net/AS210860 https://ipv4.bgp.he.net/AS210860. CIDR Report independently classifies the AS as "NOT Announced" — not currently used to announce prefixes in the global routing table, nor as a visible transit AS — listing it under EDEKA_DIGITAL, DE https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0. RIPEstat's RIS panel agrees that the AS does not originate prefixes visible in RIS and is not seen in RIS as transiting https://stat.ripe.net/resource/AS210860. IPinfo labels the AS Inactive with zero prefixes https://ipinfo.io/AS210860.

Four observers with four data pipelines produce the same operational verdict: for roughly six months as of this article's date, AS210860 has announced nothing. That consensus is the strongest evidence layer in the case — stronger, ironically, than the registry layer, where the authoritative source is unreadable. It is also the layer most responsible for the DFINFRA question's shape. A registry assignment to a role handle is a fact about administration; an AS that announces no prefixes for six months is a fact about operation, and the operation is the absence of it.

The commercially meaningful reading is not that DFINFRA operates a hidden network. It is that whatever the aut-num's administrative identity is, the observable network behaviour associated with it has stopped — and has stayed stopped across every measurement source that can see the routing table.

Two caveats keep this honest. First, absence from the routing table is a measurement statement with a measurement window. HE's page carries an update stamp (14 July 2026 per secondary coverage), and each observer's snapshot cadence differs; the consensus is over overlapping windows, not a single synchronised instant. Second, zero announcements does not establish zero RPKI authorisations globally — HE's views show zero RPKI-originated entries in its own accounting, but a ROA that authorises prefixes for a currently-unannounced AS is exactly the kind of object that would not surface in an origination-based view.

The ROA-state question remains open for the same reason the route-object question does: neither was directly queryable in this run.

The peer record adds one more contradiction to keep visible. HE reports a single observed peer, AS9211 https://bgp.he.net/AS210860; secondary coverage reports that IP.CC attributes a peer relationship to AS32787, Akamai Technologies — an attribution not visible in the IP.CC fragment retrieved for this article, and irreconcilable with a network that announces nothing, since peers require announced routes to exchange. Until that attribution is either reproduced or retired by its source, it belongs in the contested set, not the findings.

The open route-object question

The September 2026 methodology article identified the route-object layer as the endpoint that would settle whether AS210860's assignment is accompanied by any routing assertion. The answer remains pending, and this article's contribution is precision about why.

No route or route6 object for AS210860, or for 193.21.248.0/21, appeared in the object sets reproduced by either WHOIS mirror https://whois.ipip.net/AS210860 https://ip.cc/topic/asn/AS210860/. But this absence is weak evidence by construction. Route objects are keyed by prefix, not by AS number; an aut-num lookup does not return them. A mirror's AS-number page shows route objects only incidentally, and their absence there proves nothing about their existence in the database. The correct query is an inverse-origin lookup — ask the RIPE Database for all route objects whose origin is AS210860 — and the correct tool for that query, per RIPE's own documentation, is the REST API at rest.db.ripe.net, which supports single-object and inverse lookups with unfiltered, unformatted and JSON parameters, and exposes object version history through a documented path https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries.

That API was documented in the retained record; it was not executed in this run. This is the article's second honest negative. The first negative — the shell returned by the web UI — is a structural property of the endpoint. The second negative — the REST path not executed — is a scope limit of this investigation, and it differs from the first in kind: it is closable.

A next investigation that issues the inverse-origin query and a current ROA query against RIPE's NRTM or API surfaces would, in one pass, either find route objects binding prefixes to AS210860 (which would partially close the recorded-to-authorized gap) or establish their absence in the live database (which would confirm the routing silence has a registry-layer mirror, not just a measurement-layer one). Either outcome is a state difference worth publishing. Neither is claimed here.

What changed since September, stated exactly

The comparison against the September 2026 coverage should be made on the record's own terms: which observable values differ.

Routing: no change. September coverage documented the routing silence since 26 March 2026; every observer retained here continues to show zero announcements, and one editorial synthesis over secondary sources, published after September, stated plainly that after the silence "nothing observable changed" — routing observers agree on continued absence, the aut-num and the DFINFRA role remain last-modified 27 October 2021, and only the organisation object shows a 2026 modification https://bgp.he.net/AS210860 https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0 https://stat.ripe.net/resource/AS210860. This run's evidence is consistent with that synthesis on the routing layer.

Registry objects: unresolved, with sharpened coordinates. The aut-num's 2021-10-27 last-modified was already known. What this run adds is the verbatim agreement of two independent mirrors on the full aut-num body — which upgrades the aut-num's mirror-derived values from single-source observation to double-source corroboration — and the precise shape of the disagreement on the org object: same handle, two names, two last-modified values, five months and four years apart https://whois.ipip.net/AS210860 https://ip.cc/topic/asn/AS210860/. The org object's 2026-05-13 modification on one mirror remains the only candidate 2026 registry change in the record, and it remains unverified.

Status layer: newly adjudicated in part. September coverage reported RIPEstat's RESERVED rendering as an unresolved conflict. This run adds the first-party documentation showing that RESERVED is not a possible aut-num status value, which converts an open registry dispute into a partially explained data-layer difference with a residual open question https://stat.ripe.net/resource/AS210860 https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects/.

The control chain: unchanged, and now with a named reason. September defined the chain from registration to operational control and conceded it could not close. This run re-attempted the authoritative read, reproduced the failure against the same endpoint, and can now state the gap's cause as a structural property of the retrieval surface rather than an accident of one research session https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num.

That is the whole state difference, and it is modest. Modest is the honest finding. The September articles' conclusions stand; this article's value is that their open endpoints are now more precisely located, two of them (the authoritative read, the org-object freshness) have been re-tested with dates and outcomes recorded, and the remaining closable step — the inverse-origin and ROA query — is named as the next condition required for real change.

Evidence boundaries

Every registry field value in this article is mirror-derived and labelled as such. The authoritative RIPE Database web UI lookup returned no object data in either this run or the September 2026 coverage, and no first-party registry value exists in the retained record https://apps.db.ripe.net/db-web-ui/lookup?key=AS210860&type=aut-num. The RIPE REST API path that would provide machine-readable first-party values is documented but was not executed here https://docs.db.ripe.net/How-to-Query-the-RIPE-Database/RESTful-API-Queries. RIPEstat's panels are dated snapshots of a client-rendered service read through provider-reported excerpts, not verbatim captures https://stat.ripe.net/resource/AS210860. Routing observations are derived from listing and report pages with differing snapshot cadences, not from continuous measurement https://bgp.he.net/AS210860 https://ipv4.bgp.he.net/AS210860 https://www.cidr-report.org/cgi-bin/as-report?as=AS210860&view=2.0 https://ipinfo.io/AS210860. No claim in this article asserts that DFINFRA owns, operates, controls or earns from any network. No claim asserts the opposite. The directory entry for DFINFRA is maintained at https://btw.media/en/directory/dfinfra, and readers should treat it as the investigation's index, not its conclusion.