Lab notes · 2026-09-18

Who checks the anycast vendors of Europe's ccTLDs? Nobody. So we did.

31 country-code TLDs and .eu measured from RIPE Atlas probes inside each country, 26 and .eu with enough probes at home. Which of a registry's nameserver operators actually answers at home, and how far away the others are.

Why this measurement

Most European ccTLDs do not run all of their nameservers themselves. They keep a few servers at home and add secondaries from outside: commercial anycast operators (Netnod, PCH, RcodeZero, CIRA, CentralNic, UltraDNS, CommunityDNS) and other registries (DENIC, AFNIC, ACOnet, NIC.br) that host each other's zones. Our TLD inventory of 12 September found that 47 % of ccTLDs are hybrid and only 3 % sit in a single autonomous system.

Every one of those operators publishes a map of its sites. None of them can tell a registry the one thing it would want to know: from inside my own country, which of my nameservers do resolvers actually converge on, and if that one fails, how far away is the next?

We asked RIPE Atlas. For each ccTLD we took the dual-stack probes located in that country (up to 50), sent one SOA query with NSID to every nameserver address of the ccTLD, IPv4 and IPv6 with the same probes, and kept for each probe the fastest answer. That is what a recursive resolver does over time (SRTT selection), so "fastest address per probe" is the operator a country's resolvers end up using.

How fast a country reaches its own ccTLD

Dot plot with one row per ccTLD, 27 rows sorted by IPv4: median of the fastest nameserver answer from probes inside the country, IPv4 as dots and IPv6 as diamonds, all between 1.5 and 13 ms, with guide lines at 10 and 20 ms
One row per ccTLD, 27 rows sorted by IPv4. Median of the fastest nameserver answer from probes inside the country, IPv4 and IPv6 with the same probes. No ccTLD is named.

Every one of the 27 zones with enough probes answers its home country in under 13 ms at the median. The spread runs from 1.5 ms to 11.2 ms on IPv4. IPv6 sits within a millisecond of IPv4 for 21 of the 27; the largest gaps are 3.1 ms and 1.6 ms slower on IPv6 in two zones. The 90th percentile stays under 25 ms for 25 of the 27 zones on IPv4 and for 20 of the 27 on IPv6. Nothing here is broken. This note is not about outages, it is about who carries the traffic.

Failures: after removing intercepted probes (below), between 0 and 3 probes per country got no answer from any address, the 3 being one country's IPv6 set of 33 probes, which is the normal Atlas baseline, not a registry problem.

Who answers at home

In 12 of the 26 ccTLDs the registry keeps servers of its own next to outside operators. In 6 of those 12 the registry's own servers win the majority of home probes on IPv4; the outside secondaries are there but rarely the fastest. In 5 the winner share splits: in one Nordic zone a commercial anycast operator takes 58 % of home probes ahead of the registry's own servers, in one Central European zone three operators split the home traffic 40 / 36 / 21, and in one Baltic zone a domestic research network that hosts a secondary takes 46 % ahead of the registry's one own address at 21 %. In the last one the registry's own label covers a single leftover address next to the registry's servers that our inventory knows by name. Registries whose servers the inventory attributes by name (nic.at, CZ.NIC, SIDN, DNS.PT and others) are counted under that name, not in this group. In the 11 ccTLDs with a single operator, ten of them the registry itself and one a commercial anycast operator, that operator wins by definition, at 2.5 to 11 ms.

The vendors, seen from inside the countries they serve

Horizontal bar chart, one IPv4 and one IPv6 bar per operator: registry's own servers, Netnod, PCH and RcodeZero between 5 and 10 ms; DENIC, CIRA and AFNIC between 12 and 41 ms; each operator labelled with the number of foreign ccTLDs it serves in this set
Operators serving three or more of the measured ccTLDs other than their own. Per ccTLD the median of the operator's best address across the home probes, then the median across its ccTLDs. IPv4 and IPv6.

For every operator that serves three or more of the measured ccTLDs other than its own we took, per ccTLD, the median of that operator's best address across the home probes, then the median across its ccTLDs. An operator is counted only for zones whose registry it is not, so DENIC without .de and AFNIC without .fr; the registry's own servers are the home zone by definition.

OperatorccTLDs served hereIPv4 median at homeIPv6 median at home
registry's own servers125.7 ms4.8 ms
Netnod77.6 ms7.7 ms
PCH88.2 ms7.6 ms
RcodeZero109.1 ms10.3 ms
DENIC511.6 ms12.4 ms
CIRA423.2 ms19.9 ms
AFNIC341.4 ms20.7 ms

Two groups. The commercial anycast operators (Netnod, PCH, RcodeZero) answer within about 10 ms of home, in the same range as the registry's own servers. The registry-to-registry secondaries (DENIC, CIRA, AFNIC hosting other ccTLDs) answer from 12 to 41 ms away on IPv4 and 12 to 21 ms on IPv6; ACOnet, with two foreign ccTLDs just below the three-zone cut, from 35 and 42 ms. That is not a defect: those arrangements exist for global resilience, and 30 ms is a fine failover. But it means the failover order a registry assumes and the one its resolvers would take are two different things, and today nobody measures the second.

Individual extremes stay out of this note and go to the registries directly: one secondary answers a ccTLD's home country from 237 ms away on both families, one ccTLD's only outside secondary is 30 ms away, one operator's single address shows a 90th percentile of 114 ms inside the country it serves, and one commercial operator serves a ccTLD under the registry's own letter name from 54 ms away with a 90th percentile of 185 ms.

A side finding: 2 to 10 % of home probes never reach the registry

In three countries 3 to 5 of about 50 probes got SERVFAIL or REFUSED for the ccTLD's own SOA, from an answerer without NSID, or with the NSID of a public resolver. That is a home router or an ISP redirecting port 53 to its own resolver. In one case the interceptor identified itself as a DNS4EU node. We removed those probes before computing anything above; a registry that reads its own Atlas measurements without this step will see phantom failures.

Method, so you can check it

What a registry can do with this

Ask your operators for their maps, then ask a third party where your own resolvers actually land. And put NSID into the contract: an operator that does not set it cannot be checked by anyone, not even by the registry paying for it. Of the 359 addresses that answered, 84 never returned one, almost a quarter. Every commercial anycast operator in this set (Netnod, PCH, RcodeZero, CIRA, CentralNic, UltraDNS) sets it on every address; CommunityDNS is the one exception. The missing identifiers sit with registries' own servers and with registries hosting each other's zones. For those addresses, "which site answered" is a guess, and any failover measurement stops at the address. The per-ccTLD report behind this note (all addresses, all home probes, failover order, IPv4 and IPv6, intercepted probes listed) is a one-off we run on request, independent of any operator.

We do not publish per-zone results. Where a zone's setup looks like a problem rather than a choice, the operator hears it from us first (see anycast.org for the disclosure rules).

What comes next

The registries in this set hear their own numbers first, with the failover order and the per-address results behind them; a second measurement after a change is the natural follow-up, and we run it on request. The delegation side of the same continent, read without probes, is in How Europe delegates, and How German sectors delegate (20 September) goes wide on one country.

The other side of the same question, read from the root zone instead of measured: Who changed their ccTLD nameservers this year lists every ccTLD delegation change of the last twelve months and the ten operator swaps among them.