Summary

  • A frozen 11 September count of RIPE NCC’s hosted-node ledger finds 43 operational AuthDNS rows and five decommissioned ones. That is a reproducible inventory result, not a measure of how many resolver populations gained a shorter or more resilient path.
  • RIPE NCC’s Q3 2026 plan targets large eyeball networks, their peers and useful IXP ports. Its own RIPE Atlas study shows why the distinction matters: a node in Bahrain was used predominantly by probes in Saudi Arabia, while probes in Bahrain’s Batelco network hardly ever reached it.

Forty-three green rows

A green operational label is a satisfying unit of progress. It says that a machine exists, that a hostname has been assigned and that the service operator considers the instance live. On RIPE NCC’s “All hosted nodes” page, it also comes with a place, a host organisation and, often, a completion date. Those are useful facts. They are the beginning of an operating record.

They are not the end of one.

The page captured for this article contains 48 AuthDNS rows. Forty-three are operational and five are decommissioned. Among the operational rows, node #523 in Milan, hosted by LAKENETWORKS, records completion on 18 June 2026. Node #520 in Berlin, hosted by BCIX Management GmbH, records 28 July. Both dates follow the 11 June update of RIPE NCC’s Q3 plan. That chronology should not be promoted into a causal claim: the public files do not say when either application began, whether the Q3 item caused it, or which diagnosed gap either node was meant to close.

What the inventory proves is narrower and sturdier. On the capture date, the page represented 43 hosted AuthDNS instances as operational. It did not present 43 latency reductions, 43 new large-eyeball catchments or 43 independently tested resilience gains.

The objective is already written in routing language

RIPE NCC’s quarterly plan does not describe coverage as a contest to accumulate countries. It says the organisation wants to improve AuthDNS coverage in areas where it is “not very well represented”. It wants hosted nodes in large eyeball networks in a country, or in networks that peer with those eyeballs. An IXP port would also help because it allows peering with multiple parties. The item is marked in progress.

Each phrase points away from simple geography. An eyeball network is important because it aggregates the resolvers and access paths used by people and organisations. A peer matters because routing policy determines whether that traffic sees the local announcement as attractive. An exchange port is useful because it can enlarge the set of networks with a direct path. A server’s postal address proves none of those outcomes by itself.

The plan does not publish a numerical target, a denominator of under-served countries, a list of target networks, a latency threshold or an acceptance period. This does not prove that RIPE NCC lacks internal engineering criteria. It establishes only that a reader cannot join the public planning statement to the public node rows and reproduce a coverage result.

One service, two deployment layers

AuthDNS is more consequential than an ornamental point on an infrastructure map. RIPE NCC says the service announces 193.0.9.0/24 and 2001:67c:e0::/48 from AS197000. It serves reverse-DNS zones under in-addr.arpa and ip6.arpa, ripe.net, infrastructure zones of the other Regional Internet Registries, zones for supported organisations and secondary service for some country-code top-level domains.

The architecture has two visibly different layers. Four core instances in Amsterdam, London, Stockholm and Tokyo use routers to distribute queries across multiple servers running a mix of BIND, Knot DNS and NSD. Hosted instances supplement that core capacity. RIPE NCC describes those as single-server deployments placed in ISP networks or connected to Internet Exchanges.

That division is worth retaining when coverage is discussed. A hosted node can shorten a path and offer another anycast destination without acquiring the component diversity of a core site. Conversely, a core site with multiple servers does not guarantee that a particular resolver population will select it. “Node”, “site”, “server”, “catchment” and “resilience” are not interchangeable accounting units.

Bahrain is the useful counterexample

RIPE NCC has already published the method needed to move beyond map arithmetic. In a December 2024 RIPE Labs study, it used RIPE Atlas probes in South East Europe, Central Asia and the Middle East to query 193.0.9.7 for 150.6.0.193.in-addr.arpa every 30 minutes. The analysis recorded which AuthDNS server answered and aggregated observations by probe and day, including median round-trip time.

The results made physical location look properly modest. In South East Europe, many probes reached Amsterdam. Local nodes dominated in Bosnia and Herzegovina and especially Romania, while some probes consistently reached Kansas City or Bahrain. In Central Asia, the study said there was then no regional AuthDNS instance; most queries went to Amsterdam or Stockholm.

The Middle East provided the cleanest warning against reading a city label as a service territory. RIPE NCC had a node in Manama, Bahrain, hosted by STC Bahrain. Yet that instance was used predominantly by probes in Saudi Arabia. Probes inside Batelco’s Bahrain network, AS5416, hardly ever reached it. Saudi Telecom Company’s AS25019 did so throughout the measurement window. For the Saudi probes, Bahrain was also the better-performing observed destination: median round-trip times were below 50 milliseconds, compared with roughly 100 milliseconds for European instances and much longer paths to Venezuela or Guam.

Nothing in that result says the Bahrain node failed. It says something more useful: BGP catchment is the product being delivered. A node can be physically local to one country and operationally local to another network population. The route chosen reflects announcements, preferences, peering and upstream structure, not the distance between two pins on a map.

The peering policy explains why

RIPE NCC’s AuthDNS peering policy gives the mechanism a public frame. AS197000 follows a generally open policy. At core and hosted IXP nodes, it accepts routes from exchange route servers subject to minimum prefix sizes of /24 for IPv4 and /48 for IPv6, and advertises its own prefixes to those route servers. It encourages use of route servers and their filtering communities. Direct peering is considered under stated conditions; for hosted IXP nodes it is considered where route servers are absent.

These rules can make one placement visible to many networks, or leave its useful catchment narrower than a map suggests. They also show why a host organisation’s name is not a peer-set receipt. The public node ledger does not enumerate, for each AuthDNS instance, the host network’s ASN, route-server participation, observed incoming resolver cohort or the change in that cohort after activation. Some of those details may be sensitive or unstable. The answer is not maximal disclosure. It is a bounded measurement record.

Caches shrink the relevant denominator

The Hosted DNS FAQ adds a second discipline. Most DNS queries are answered by caches. For a well-connected network, RIPE NCC says the local benefit of hosting a node may be modest or nonexistent; only a very small fraction of queries for the relevant high-level zones reaches a root or AuthDNS server. A local instance may improve those queries when the existing path is unusually long, but it should not be sold as a general reduction in all DNS latency or upstream bandwidth.

The host and RIPE NCC also control different pieces. The host supplies the specified server or a suitable virtual machine, colocation conditions, redundant power, physical security and connectivity, and bears its costs. RIPE NCC manages the server remotely. If it observes a problem with the node or its reachability, the server withdraws the prefix so traffic can move to other DNS servers.

That fail-away behaviour is valuable, but it underscores the measurement problem. Withdrawal can alter catchment without changing the inventory’s physical location. A new peering arrangement can alter catchment without adding a node. A decommissioned row can remove a path whose traffic had already shifted elsewhere. The row count and the routed result live on different clocks.

An inventory receipt and a coverage receipt

RIPE NCC should keep the hosted-node ledger. It is legible, current enough to expose additions and removals, and better than a decorative map with no identities or dates. The missing piece is a separate coverage receipt tied to the objective that the quarterly plan has already stated.

Such a receipt need not reveal private peerings or individual resolver traffic. It could bind a node ID or placement campaign to a target geography and an aggregate baseline cohort; cite a RIPE Atlas measurement ID, eligibility rule and observation window; report the distribution of responding nodes and round-trip times before and after activation; state the target condition, exceptions and sample limitations; and record the date on which the result was accepted or left open.

The receipt must keep five conclusions separate. Inventory says that an instance is listed and operational. Reachability says that a vantage can obtain an answer. Catchment says which instance the routing system selects. Latency describes the observed path at a stated time. Resilience asks what happens when a node, route or upstream dependency disappears. One number cannot answer all five questions.

The 43 operational rows are therefore not an indictment. They are a credible first ledger waiting for the second one that RIPE NCC’s own planning language makes necessary.

Sources