Summary

  • The RIPE aut-num AS210764 carries as-name ISC-AGP1, organisation ORG-ISCI1-RIPE (Internet Systems Consortium Inc.), status ASSIGNED, and was created and last modified at the same instant: 2021-09-13T14:46:22Z.
  • The object names two maintainers — RIPE-NCC-END-MNT and MAINT-ISC — and two routing neighbours, AS3557 and AS42229, in its import and export policy.
  • Independent measurements show the ASN announcing nothing since 3 February 2023, yet PeeringDB still lists it as an ISC F-root node in Dushanbe with RIR status marked ok.
  • The organisation object ORG-ISCI1-RIPE was last modified on 13 May 2026, while the aut-num itself has been untouched for over four years.
  • The second named neighbour, AS42229, could not be verified in this investigation; its operator is not asserted here.

Internet registration records are usually read as identity documents: this number belongs to that organisation. For AS210764 the more useful reading is procedural. A registration is not only a statement that Internet Systems Consortium Inc. holds an autonomous system; it is a standing answer to the question of who may change that statement, under what authentication, and with what counterweights. Reading the record that way turns the ISC-AGP1 entry from a curiosity into a small case study in how the RIPE Number Registry distributes administrative authority — and where the public trail goes quiet.

The object and its frozen timestamp

The RIPE aut-num object for AS210764 is compact. Its as-name is ISC-AGP1. Its organisation attribute is ORG-ISCI1-RIPE, which resolves to Internet Systems Consortium Inc. Its status is ASSIGNED. Its source is RIPE. The object was created at 2021-09-13T14:46:22Z and last modified at exactly the same timestamp — meaning that in more than four years, nobody has altered a single attribute of the registration itself [https://rest.db.ripe.net/ripe/aut-num/AS210764.json] [https://whois.ipip.net/AS210764] [https://stat.ripe.net/resource/AS210764] [https://bgp.he.net/AS210764] [https://ipgeolocation.io/browse/asn/AS210764].

The same instant of creation and last modification matters because RIPE records are living documents: every update writes a new last-modified value. A record frozen at its creation timestamp has simply never been edited. Whether that stillness is prudence, neglect or an artefact of the record's control structure is precisely what the rest of the chain is needed to interpret.

One point of attribution should be handled carefully. This investigation could not open the canonical RIPE Database REST document for the aut-num directly; the attributes above are corroborated across several independent renderings of RIPE data, including RIPEstat, which is operated by the RIPE NCC itself, and third-party mirrors that reproduce the full RPSL record. Where those renderings agree — and here they agree on every attribute — the picture is consistent, but a first-party retrieval remains the gold standard, and the uncertainty is recorded rather than resolved [https://stat.ripe.net/resource/AS210764] [https://whois.ipip.net/AS210764].

Two maintainers, two kinds of authority

The aut-num's mnt-by attribute lists exactly two maintainer objects: RIPE-NCC-END-MNT and MAINT-ISC. Under RIPE's own documentation, a maintainer referenced by mnt-by is what authenticates any update to the object; credentials are checked as a logical OR, and RIPE NCC creates top-level objects for resources its members receive, with the member selecting a default maintainer that appears in mnt-by [https://docs.db.ripe.net/Database-Support/Database-Security/].

The two names carry different weights. RIPE-NCC-END-MNT is described in RIPE staff discussion on the db-help list as the maintainer for direct, end-user resources: objects carrying only that maintainer are updated through the RIPE NCC itself, and its maintainer status generally cannot be changed by the holder (RIPE db-help staff guidance). MAINT-ISC, by contrast, is a self-selected maintainer in the organisation's own control. The combination means two parties can each independently authorise changes to AS210764: the RIPE NCC, through its end-user maintainer role, and ISC, through its own credential set. Neither can revoke the other's listed authority without the other's cooperation — a deliberately joint structure that is common for resources assigned to end users but still worth stating precisely, because it defines who could, in principle, alter the record tomorrow.

That structure also answers the dormant-assignment question partially and negatively. A record that only the registry could touch would be an odd thing for a functioning operator to hold. A record with an organisational maintainer still active in mnt-by is the standard shape of an end-user assignment where the holder retains a live channel to its own registration — whether or not that channel has been used since 2021.

The organisation object is not frozen

The contrast comes from the linked organisation. ORG-ISCI1-RIPE — org-name Internet Systems Consortium Inc., org-type LIR, registration number 3618975 in Delaware, country US — was created on 26 June 2013 but last modified on 13 May 2026 at 07:34:54Z [https://whois.ipip.net/AS210764] [https://ipgeolocation.io/browse/asn/AS210764]. Something about the organisation's registration was maintained less than five months before this investigation's retrieval window, while the aut-num attached to it has not moved since the day it was created.

This asymmetry is the single most informative signal in the chain. It shows the organisation's relationship to the RIPE Database is administered and current: contact data, abuse handling or other organisation attributes were recently revisited. It does not show that anyone has reviewed the AS210764 assignment itself. Registry freshness is per-object, not per-holder, and the pair of timestamps — 2021 for the number resource, 2026 for the organisation — captures that distinction exactly.

Neighbours: the mechanism the record implies

The aut-num's routing policy names two neighbours: it imports "from AS3557 accept ANY" and exports "to AS3557 announce AS210764", and the same pair of lines exists for AS42229 [https://whois.ipip.net/AS210764]. Policy lines in an aut-num are declarations of intent, not observations of live BGP, but they encode the mechanism the registrant expected: this local node would learn routes from its neighbours and offer its own number upward.

AS3557 is well documented as ISC's F-root originating ASN. The RADB-sourced aut-num for AS3557 is named ISC-F-ROOT, described as Internet Systems Consortium, Inc., with remarks stating it is "used to source advertisements of F-Root prefixes" and that "3557 will never peer directly"; it was last modified on 13 November 2023 [https://bgp.he.net/AS3557] [https://radar.qrator.net/as/3557/whois] [https://rest.db.ripe.net/ripe/aut-num/AS3557.json]. ARIN allocated AS3557 to Internet Systems Consortium on 21 April 1994 [https://ipgeolocation.io/browse/asn/AS3557]. ISC's own page states it has operated the F-Root — one of the thirteen Internet root name servers — since 1994, answering queries over IPv4 on 192.5.5.241 and IPv6 on 2001:500:2f::f using hierarchical anycast and BIND 9 [https://www.isc.org/f-root/]. PeeringDB describes AS3557 as existing to source the F-Root anycast prefixes, with peering available with the local ASN active at an exchange point [https://www.peeringdb.com/asn/3557].

The pattern extends across ISC's RIPE registrations. A companion aut-num, AS210762 with as-name FROOT_TGD1, sits under the same organisation ORG-ISCI1-RIPE and carries an identical policy shape: import from AS3557, export to AS3557 [https://whois.ipip.net/AS210762]. Two RIPE ASNs, both named for F-root sites, both wired to the same originating ASN, form a coherent design: per-site local numbers that peer upward with the global F-root source ASN rather than with the world.

AS42229 is the exception. This investigation could not establish who operates it; retrieval attempts failed and no attributable evidence was obtained. It is treated here as an unresolved named neighbour — a number the record cites but this article cannot characterise. That gap is stated plainly rather than filled with inference.

What the measurements see — and do not

Whatever the policy lines declare, the routing world observes nothing. Hurricane Electric's data shows AS210764 has not been visible in the global routing table since 3 February 2023, announcing zero prefixes; IPinfo characterises the ASN as Inactive with zero addresses [https://bgp.he.net/AS210764] [https://ipinfo.io/AS210764]. Meanwhile, PeeringDB's self-reported record lists AS210764 as "ISC F-ROOT DYU1", a Dushanbe, Tajikistan F-root node, with website isc.org, IRR as-set AS-FROOT, and RIR status ok as updated on 26 June 2024 [https://www.peeringdb.com/net/27983].

These are different kinds of claim from different kinds of source. The routing invisibility is an independent measurement. The PeeringDB entry is self-reported by the network and maintained by a community registry; its 2024 update shows someone asserted the record's validity more recently than the aut-num was touched, but self-attestation is not corroboration, and ISC's own F-root page does not name a Dushanbe node in the material available to this investigation [https://www.peeringdb.com/net/27983] [https://www.isc.org/f-root/]. A design in which local F-root nodes announce prefixes under NO_EXPORT-style constraints would explain some invisibility by intent; the published record available here does not document that design for AS210764 specifically, so the invisibility remains observed, not explained.

A small rendering footnote

Hurricane Electric renders AS210764's administrative and technical contacts as DUMY-RIPE because it strips personal data, while the ipip.net mirror shows IAC75-RIPE — the same handle the organisation object uses for its abuse contact. The difference is a privacy-processing choice by one aggregator, not a discrepancy in the registry [https://whois.ipip.net/AS210764] [https://bgp.he.net/AS210764]. It is worth recording because contact handles are part of the accountability chain: who answers when a registration needs attention.