Summary

  • The RIPE aut-num object AS210764 (as-name ISC-AGP1) names Internet Systems Consortium Inc. as its organisation and is maintained by MAINT-ISC, a maintainer string that plausibly belongs to ISC's own operations, but the object itself proves registration, not operation.
  • RIPEstat's RIS, Hurricane Electric's toolkit, Qrator Radar, IPinfo and IPGeolocation all report zero prefixes originated by AS210764; Hurricane Electric dates the ASN's disappearance from the global routing table to 3 February 2023.
  • PeeringDB, a self-reported database, describes AS210764 as "ISC F-ROOT DYU1" with an operational 10G peering at the TJ-IX exchange in Dushanbe and a claimed 5 IPv4 and 5 IPv6 prefixes — a count that conflicts with every independent measurement.
  • ISC's own F-root documentation states that F-Root uses a different peering ASN at each location and that local nodes advertise the more-specific prefixes 192.5.5.0/24 and 2001:500:2f::/48 to peers with the NO_EXPORT community. That mechanism makes zero global visibility the expected behaviour of a working local F-root node — which is why the same observation cannot distinguish a healthy node from a dead one.

What the registry actually registers

The RIPE Database entry for AS210764 is the anchor of this story, so it is worth reading it precisely. The aut-num object carries the as-name ISC-AGP1, references organisation ORG-ISCI1-RIPE, and declares two import policies — accepting ANY from AS3557 and from AS42229 — and symmetric export policies announcing AS210764 to both. Its status is recorded as ASSIGNED, its maintainers are RIPE-NCC-END-MNT and MAINT-ISC, and it was created on 13 September 2021 at 14:46:22 UTC, with no recorded later modification.

The administrative and technical contact fields appear as DUMY-RIPE on Hurricane Electric's copy of the object — a redaction marker RIPE applies when personal data is removed — while third-party mirrors such as IPIP.NET and IPGeolocation.io render the pre-redaction values, pointing to role object IAC75-RIPE, "ISC Abuse Contacts".

The referenced organisation is more unambiguous. ORG-ISCI1-RIPE is Internet Systems Consortium Inc., country US, Delaware registration number 3618975, org-type LIR, with a Newmarket, New Hampshire postal address, the NOC contact address published in ISC's RIPE record, and a creation date of 26 June 2013. This is the same Internet Systems Consortium, Inc. that operates the F root name server, one of thirteen root name servers, which ISC says it has run since 1994 on hierarchical anycast with over 230 nodes and almost 3,000 peers.

So the registration chain is clean: a RIPE autonomous system, registered in 2021, whose organisation object is the American nonprofit that runs a root server, maintained under a maintainer handle that mirrors ISC's own abuse-contact identity. If you look up AS210764 in RIPEstat, you get a one-line summary that collapses this chain: "Name and holder of this ASN: ISC-AGP1 Internet Systems Consortium Inc."

What the registration does not tell you is whether any router anywhere has ever announced a prefix under AS210764 — and that is where the record gets interesting.

What independent measurements show

Four independent observation systems, sampled independently of each other, agree on the same picture.

RIPEstat's routing section, which draws on RIPE NCC's RIS route collectors, reports that AS210764 "does not originate prefixes visible in RIS" and "not seen in RIS as transiting", with zero prefix details. Hurricane Electric's BGP toolkit goes further and dates it: the ASN has not been visible in the global routing table since 3 February 2023, and shows zero prefixes originated in both IPv4 and IPv6, zero RPKI-originated-valid entries, zero originated IP addresses and zero observed AS paths. Qrator Radar independently shows 0 prefixes, 0 visibility and 0 RPKI ROAs.

IPinfo labels the ASN "Inactive" with zero prefix, peer and route counts, and IPGeolocation.io reports zero IPv4 and zero IPv6 routes.

Two caveats attach to this unanimity. First, these are sampled measurement systems: a route collector network does not see every point of exchange on the Internet, so "not observed" is not proof that "never announced" — particularly for announcements deliberately confined to a single exchange fabric. Second, the systems are not fully independent of one another in practice: aggregators such as IPGeolocation.io and IPIP.NET largely mirror RIPE objects and shared measurement feeds, so the true number of independent vantage points is smaller than the number of agreeing pages.

Still, the direction of evidence is consistent: the global routing system currently sees nothing from AS210764.

What PeeringDB and the IXP tracker claim

Against that consensus stands a self-reported record with a different story. PeeringDB's entry for network 27983 names AS210764 "ISC F-ROOT DYU1", lists the organisation as Internet Systems Consortium, Inc. (ISC), points to isc.org, declares the IRR as-set AS-FROOT, reports RIR status "ok" as of 26 June 2024, and claims 5 IPv4 prefixes and 5 IPv6 prefixes, with the record last updated 16 January 2026. Its single facility entry is a public peering at TJ-IX in Dushanbe, Tajikistan, at IPv4 address 194.117.50.27 over a 10G port, marked operational.

The Internet Society's Pulse IXP tracker independently corroborates the exchange membership: its TJ-IX member list includes "ISC F-ROOT DYU1", AS 210764, port speed 10 Gbps, open peering policy, not peering at the route server, registered in the United States. Hurricane Electric's TJ-IX page places AS210764 on the same exchange fabric at the same address, among twelve members.

These two source classes measure different things. PeeringDB is a database operators fill in about themselves; a claimed prefix count there may describe configured intent, planned announcements or simply a stale entry, and the tracker derives partly from PeeringDB itself. Exchange membership records a port on a fabric, not routes originated across it. So the strongest self-reported claim — five and five prefixes — has no independent measurement behind it, and the strongest independent measurements — zero, everywhere — have no self-reported support either.

The record that bridges them is the "DYU1" label, which follows the IATA code for Dushanbe and matches ISC's convention of naming root-server nodes by city.

The mechanism that explains invisibility — and complicates interpretation

ISC's own documentation supplies the missing context, and it is the reason this report cannot simply conclude that AS210764 is dead.

ISC's F-Root peering page states that F-Root uses a different peering ASN at each location, and that networks filtering on registry objects should use the AS-FROOT as-set rather than any single ASN. It further states that local nodes advertise the more-specific prefixes 192.5.5.0/24 (IPv4) and 2001:500:2f::/48 (IPv6) to peers with the NO_EXPORT community, while global nodes advertise the covering prefixes 192.5.4.0/23 and 2001:500:2e::/47 via Tier-1 transit.

An ISC blog post on F-root routing elaborates: global nodes anycast the /23 and /47, and local nodes in over 50 locations announce the /24 and /48 with NO_EXPORT so that only the local community uses them.

The NO_EXPORT design has a precise consequence for measurement. A prefix announced to a handful of peers at a single exchange, tagged so it must not leave those peers, will be invisible to every route collector that is not itself a peer on that fabric. Zero global visibility is therefore exactly what a functioning local F-root node looks like from the global routing table.

But note what this mechanism gives and what it does not. It explains how AS210764 could hold five prefixes and show none. It does not tell you whether any session at TJ-IX is currently up, whether the node is actually originating the /24 and /48 to its local peers, or whether the PeeringDB entry still reflects a machine that answers. An exchange member that persists in a directory while announcing nothing — even locally — is indistinguishable, from the outside, from an entry whose BGP sessions are down, misconfigured, or never re-established after a change in 2023.

Three explanations the record permits

Given the evidence above, the public record permits at least three readings, and honesty requires holding all three.

The first is the healthy-node reading. AS210764 is the Dushanbe F-root node's peering ASN; its prefixes carry NO_EXPORT; RIPEstat, Hurricane Electric, Qrator and IPinfo see nothing because they are not peers at TJ-IX; and the PeeringDB entry is accurate. Under this reading the "since 3 February 2023" date from Hurricane Electric merely marks when the last globally propagated announcement aged out — for instance, the moment a local node stopped exporting anything without NO_EXPORT, or a transit arrangement ended.

The second is the dormant-node reading. The node exists but its routing is currently inert: sessions at TJ-IX are down or the node has stopped originating even locally, while its registry objects and self-reported directory entries persist. Aggregators that list it as "Inactive" are, on this reading, closer to operational truth than PeeringDB's "operational" port status.

The third is the registry-artefact reading. The aut-num was created in 2021 for a node deployment that either never went fully live or has been retired, and the PeeringDB record — last updated January 2026 — reflects an ISC database entry maintained by habit or policy rather than a verified operational node. Nothing in ISC's own public pages, which never name AS210764 at all, contradicts this reading.

The distinction matters because each reading implies something different about ISC's stewardship claims. The first shows ISC doing exactly what its documentation says — per-location ASNs, NO_EXPORT more-specifics, exchange-local peering. The third would show a registry footprint that outlived its function, which is a mundane but real governance signal: an organisation's network identity records can drift from its operational reality with no public mechanism to reconcile them.

What the evidence cannot prove, and what would

Two evidentiary gaps deserve to be named precisely.

First, no source in this record demonstrates who operated routing equipment under AS210764, if anyone ever did. Registration binds the ASN to the organisation; measurement binds its prefixes to visibility, not to a machine's owner; PeeringDB binds the ASN to a node label because ISC entered it there. The BTW directory record for this organisation Internet Systems Consortium in the BTW directory tracks these same attribution questions at the institutional level.

Second, no source confirms or denies ISC's operational control today. ISC's own F-root pages, the most authoritative statements the organisation publishes about its routing, describe the general mechanism but never mention AS210764. The link between the ASN and F-root runs entirely through PeeringDB and the IXP tracker — the former self-reported, the latter partly derived from the former. An independent BGP observation at TJ-IX itself — a member's collector seeing the /24 or /48 arrive with NO_EXPORT from AS210764 — would settle the healthy-node reading in one datapoint.

Conversely, a statement from ISC either confirming AS210764 as the Dushanbe node's ASN or announcing its retirement would settle the rest. As of this report's research date, neither exists in public.

For operators and researchers, the practical takeaway is methodological: when a registry record, a measurement consensus and a self-reported database disagree, the NO_EXPORT mechanism shows that disagreement can be the signature of correct design rather than of failure — but it equally provides cover for failure. Attribution and activity are separate facts, and only measurement at the point of exchange, or a statement from the operator, converts one into the other.

This report's distinct question is narrower than any general examination of ISC's network identity: whether zero global visibility is consistent with the documented F-root design, and what would distinguish a silent node from an empty record.