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 identity.l.root-servers.org 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 l.root-servers.net. 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 Instance||Number of Probes||Percentage|
"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 Instance||Number of Probes||Percentage|
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 identity.l.root-servers.org 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 l.root-servers.net, 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 address||Number of occurrences|
Many of these IP addresses have a PTR record which gives us an indication of the localisation of the instance. For instance, 18.104.22.168 is hostmaster-gw1.odessa.ucomline.net. 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 kbp01.l.root-servers.org and traceroute:
% traceroute l.root-servers.net
traceroute to l.root-servers.net (22.214.171.124), 30 hops max, 60 byte packets
1 192.168.2.254 (192.168.2.254) 0.568 ms 0.426 ms 0.370 ms
2 126.96.36.199 (188.8.131.52) 6.682 ms 6.768 ms 7.904 ms
3 184.108.40.206 (220.127.116.11) 13.724 ms 13.741 ms 13.804 ms
4 rke75-1-v900.intf.nra.proxad.net (18.104.22.168) 10.622 ms 11.369 ms 11.379 ms
5 cev75-1-v902.intf.nra.proxad.net (22.214.171.124) 11.683 ms 12.649 ms 13.141 ms
6 p16-6k-1-po12.intf.nra.proxad.net (126.96.36.199) 13.150 ms 10.321 ms 10.265 ms
7 bzn-crs16-1-be1024.intf.routers.proxad.net (188.8.131.52) 12.052 ms 7.389 ms 11.070 ms
8 th2-6k-3-po21.intf.routers.proxad.net (184.108.40.206) 26.276 ms 26.311 ms *
9 jaguar-pni.routers.proxad.net (220.127.116.11) 10.974 ms 11.412 ms 11.901 ms
10 l.root-servers.net (18.104.22.168) 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.