The Many Instances of the L-root Name Server

Stéphane Bortzmeyer — Jan 20, 2014 04:50 PM
The techniques used by the L-root DNS server are documented in RFC 7108 "A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes". These techniques can be used by the RIPE Atlas probes to find the instance of L-root they are talking to.


RFC 7108 is available online. It documents the various techniques that a user can try to find out which of the instances of the anycast cloud he/she is using. Some are traditional (CH/TXT request of id.server), some more modern (NSID) and some are specific to L-root such as the name that you can resolve on your machine and that returns an IP address that is unique per instance. This last technique can be used by ordinary people, who have no access to the dig command or similar programs.


Let's first use the NSID queries to examine the many instances of L-root. We already used this technique in another article and the code is still on Github. Here, we will ask 500 RIPE Atlas probes to query the SOA of the root domain to The worldwide measurement is #1071935. It is here analysed by another program.

Among the 452 probes which got a proper NSID response, we find 109 different instances of L-root. According to RFC 7108, there were 273 different nodes (and therefore identifiers) in November 2013. We can see that the selected RIPE Atlas probes are not dispersed enough to find all the nodes. Maybe a test with more probes would help but one measurement is currently limited to 500 probes.


The most popular instances are:

Root Server InstanceNumber of ProbesPercentage 39 9% 28 6% 19 4% 16 4% 13 3% 11 2% 11 2% 10 2% 10 2% 10 2%

 "Most popular" is to be taken with a grain of salt: RIPE Atlas probes are not evenly geographically distributed.

The instances are named after the IATA airport codes. "ods" is Odessa in the Ukraine, "kbp", Kiev, also in the Ukraine, "ory" is Paris in France etc. The popularity of Ukrainian destinations is a bit surprising. It is stable (the same measure two weeks ago or one month after showed the same phenomenon.) Of course, if we measure from a different region, we get a very different picture. Limiting to probes to the "West" (the US) area, we get (measurement #1071936):

Root Server InstanceNumber of ProbesPercentage 46 10 % 43 9 % 34 7 % 34 7 % 27 6 % 22 5 % 21 4 % 16 3 % 16 3 %

Here, US cities (sjc = San Jose, atl = Atlanta, bos = Boston) get the lion share.

This change of "popularity" appears also when you measure in the South-East region (Asia-Pacific, measurement #1071938): a machine in Noumea (New Caledonia) is the most commonly used by the probes, before a machine in Perth (Australia). In North-Central (Europe, measurement #1071939), the Ukrainian sites are again in front. In North-East (Russia, measurement #1071937), we find of course the same results (but the number of probes is lower, so may be less representative).

All these measurements were done with IPv4. Testing with IPv6 show similar resultats, including the "Ukrainian attractor" (world-wide measurement #1402075).

RFC 7108 proposes another way, besides NSID, to find out to which instance you are talking to. You request the A record for the name and then you get an IPv4 address which uniquely identify the instance. Do note that, for a given probe,  it may be a different instance than the one obtain by the previous measure. In the previous measure, we used a direct connection from the probe to, but now, the probe queries its default resolver, which may be far away, and may use a different instance of L-root. So, let's see the results of measurement #1071473, 500 probes requested:

IP addressNumber of occurrences 33 26 22 20 17

Many of these IP addresses have a PTR record which gives us an indication of the localisation of the instance. For instance, is So, the Ukrainian effect was a real one. There are few RIPE Atlas probes in the Ukraine. Can it be an attraction entirely caused by BGP? Or a misconfiguration? Here is an example seen from Free/Proxad (AS 12322) in Paris (France). NSID returns and traceroute:

% traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 (  0.568 ms  0.426 ms  0.370 ms
 2 (  6.682 ms  6.768 ms  7.904 ms
 3 (  13.724 ms  13.741 ms  13.804 ms
 4 (  10.622 ms  11.369 ms  11.379 ms
 5 (  11.683 ms  12.649 ms  13.141 ms
 6 (  13.150 ms  10.321 ms  10.265 ms
 7 (  12.052 ms  7.389 ms  11.070 ms
 8 (  26.276 ms  26.311 ms *
 9 (  10.974 ms  11.412 ms  11.901 ms
10 (  22.967 ms  23.503 ms  24.502 ms

The route shows only French operators and the TTL seem consistent with a route staying in France (typical TTLs for Ukrainian targets are at least twice as large). At least in this case, we can suspect a misconfiguration.


Being able to find out which instance of an anycast cloud you use is very important for debugging operational issues. As a side effect, it also allows funny statistics. BGP never guaranteed that you get to the "closest" instance, especially if you use "closest" in the geographical sense. The most popular instances are therefore not always the ones you expect. This assume that the labels returned by the DNS server about itself are correct, which is not always easy to achieve in the very dynamic environment of the Internet.

john bond says:
Jan 22, 2014 03:18 PM
Hello Stephan,

Firstly, thank you for conducting this analysis. i preformed further investigation on the It appears that this node it is in fact very well connected. When I look at the probes that get an NSID of is see the majority of them have a directed peering with AS 20144 (traceroutes[1]) who is the host of this node. As the network is only one AS hope away it is often preferred. An example of where we see this preference is with AS 33540 where all 27 probes hit because of direct peering with AS20144 (traceroutes[2], NSIDs[3]).

In relation to AS12322 I have been unable to recreate this issue its possible that it no longer exists. I conducted a measurement[4] to be preformed by all AS12322 164 probes. I was allocated 63 and all of them return an NSID of Including probe 10645[5] which I believe is your probe and therefore has the same path[6] as above. As a final test I preformed the following query. IN A

Using tcpdump on the lys01 node i was able to see this request come in so i think we can say with confidence that this probe is hitting the lys01 node.

Another aspect which influences path choice is AS prepending. Some of our hosts prepend there AS when announcing the l-root prefix. Two examples of this can be seen via RIPEstat looking glass[7]. AS271 is prepending itself an additional 3 times at RRC03 (AMS-IX) and RRC11 (NYIIX). We also see AS35313 prepending an additional path at RRC11. These are only the examples we can see via ripe stat however we do see other examples where this occurs. L-Root hosts are free to choose how they announce our prefix so your conclusion is correct Just because an l-root node is geographically close to you it dose not necessarily mean that is the node you will use.
As a side note, I also audited all of the l-root boxes to ensure that there NSID is configured to the correct value and was able to find no issues. To analyse the atlas measurements i used Steaphans script[8] mentioned above for the NSID's and Jan Hugo Prins json2traceroute script[9] for the traceroute's

ICANN DNS Operations

Robert Kisteleki says:
Jan 28, 2014 09:02 AM
I'd also like to draw your attention to
Dmitry Kohmanyuk
Dmitry Kohmanyuk says:
Jul 09, 2014 12:42 PM
Pleasantly surprised by those statistics. We (Hostmaster) run three L-root nodes, and they
should be well-connected: Kyiv one uses Topnet (AS 21011) and Odessa - Vega Telecom (formerly Ucomline, formerly Farlep - AS41216). The third node is in Kharkiv - ITL, AS 15626.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.