Stéphane Bortzmeyer

Using RIPE Atlas User Defined Measurements to Find the Most Popular Instances of a DNS Anycast Name Server

Stéphane Bortzmeyer

12 min read

0 You have liked this article 0 times.

A DNS anycast name server has several physical instances, all behind the same IP address. Which one is used by a RIPE Atlas probe depends on the location of the probe in the BGP space. RIPE Atlas can query the physical identity of the probe and therefore help to determine which instances have the largest user base.


When you manage an anycast DNS server , you want to know which instances are visited often and are therefore important for many users and which instances serve only very few people and are therefore less crucial. You can watch the actual traffic on the instances themselves (with a tool like DSC ) and find out which machines answer the most queries. But the BGP routing being what it is, the global traffic won't tell you that. In some places, the order is quite different and an instance that is apparently used very little, can be very crucial in some countries or regions.

Luckily, the RIPE Atlas system allows you to perform this kind of survey. With the RIPE Atlas user-defined measurements you can send things like: "Ask 'SOA example.' to a name server and tell me what it replied". User-defined measurements allow to set options like NSID (standardised in RFC 5001 ), an option which allows to query a name server and to ask its name (a better version of the old "hostname.bind" trick).

RIPE Atlas measurements to anycast instances of .fr

We used the RIPE Atlas user-defined measurements to find out the relative importance of instances of , an anycast name server managed by AFNIC . It is used, among other things, for the TLD " .fr ". The name server has NSID enabled as you can see with ' dig +nsid SOA fr. '. To do the survey, we scheduled six RIPE Atlas measurements, one for the whole world and one each for the "areas" pre-defined in RIPE Atlas (in RIPE Atlas, a "measurement" is one set of configuration data, indicating things like the area; it may involve many probes and many IP packets). For only six measurements, one can use the RIPE Atlas official web interface to start them, but using the new measurement creation API has the advantage that you can capture all the setup and options in one file, and run it exactly in the same way at various intervals. The code we used can be found in the appendix at the end of the article.

RIPE Atlas measurement results

We scheduled measurements from 500 probes in total, first querying over IPv4 (remember that many probes do not have IPv6), with only one query per probe (and not repeating it if the query was lost, which explains the high percentage of network misses).

Results worldwide

Worldwide, 15 probes were not able to get a response, and 1 got a response but without NSID (an overzealous firewall stripped it?). The responses are shown in Table 1 below.

Name server instance Nr. of probes connecting to instance Percentage 173 36% 173 36% 47 10% 29 6% 25 5% 19 4% 18 4%

Table 1: Number of probes connection to each instance - worldwide

Two name servers stand out: one in Paris, and one in Frankfurt, . Note that this does not measure their actual traffic, but the size of the BGP attraction basin: one third of the probes have as the closest instance. (To draw a conclusion from the distribution of RIPE Atlas probes of the actual DNS resolvers, we would need to assume that RIPE Atlas probes are evenly distributed worldwide, which is far from true.)

There are currently eight instances of . Five are global and can potentially be seen from everywhere:

  • th2 (Paris)
  • ix1 (Paris)
  • fra (Frankfurt)
  • lyn1 (Lyon) and
  • lyn2 (Lyon).

The following three are local and have a much smaller theoretical attraction basin:

  • bru (Brussels)
  • run (la Réunion) and
  • lon (London).

Results by Region

In "West" (North-America), there were not enough probes to perform the full measurement, so we could only schedule 181 probes (6 network failures, 2 NSID failures). Note that (in Brussels) no longer appears which means none of the RIPE Atlas probes connected to this instance.

Name server instance Nr. of probes connecting to instance Percentage 95 55% 57 33% 9 5% 5 3% 4 2% 3 2%

Table 2: Number of probes connection to each instance - West

In "North-East" (Russia), the number of probes is even smaller. See the results in Table 3 below.

Name server instance Nr. of probes connecting to instance Percentage 9 39% 8 35% 5 22% 1 4%

Table 3: Number of probes connection to each instance - North-East

Similarly in "South-Central" (Africa), there are very few probes and the majority of them are located in South Africa (see Table 4).

Name server instance Nr. of probes connecting to instance Percentage 4 29% 3 21% 3 21% 2 14% 1 7% 1 7%

Table 4: Number of probes connection to each instance - South-Central

Africa and Russia are the only areas where is not the most attractive instance but the numbers are so low, they are not very significant.

For probes from "South-East" (Asia-Pacific) we saw the following results:

Name server instance Nr. of probes connecting to instance Percentage 43 38% 36 32% 10 9% 10 9% 9 8% 4 4%

Table 5: Number of probes connection to each instance - South-East

The majority of RIPE Atlas probes (and the majority of instances) are located in "North-Central" (Europe). Here, where we could schedule all 500 measurements as requested:

Name server instance Nr. of probes connecting to instance Percentage 167 35% 165 35% 44 9% 34 7% 23 5% 22 5% 20 4%

Table 6: Number of probes connection to each instance - North-Central

Note that, as a sampling effect, some instances of , such as (la Réunion) are not even seen by any of the RIPE Atlas probes.

Results received over IPv6

As you can see in the tables below, the picture is quite different: There were many more network problems (65 among 476 probes in the worldwide test). Also, the distribution of name servers has changed as you can see in Table 7 below.

Name server instance Nr. of probes connecting to instance Percentage 148 36% 68 17% 65 16% 64 16% 49 12% 12 3% 5 1%

Table 7: Number of probes connection to each instance over IPv6 - worldwide

IPv6 is much more widely deployed in Europe than in North-America. For North-America, we could only schedule measurements from 47 probes (4 of them failed), half of them connecting to the London instance.

Name server instance Nr. of probes connecting to instance Percentage 22 51% 12 28% 8 19% 1 2%

Table 8: Number of probes connection to each instance  over IPv6 - North America


A series of measurements like the ones facilitated by RIPE Atlas can help us to find out which of the DNS anycast instances were "most popular". Once we know which of the instances were connected to by the most RIPE Atlas probes, we could potentially re-adjust BGP or other operational 'knobs', if the distribution is not satisfying.

We could receive a larger set of results by doing per-country measurements (which RIPE Atlas permits). 

A test with 500 probes, such as the worldwide one or the one we did with probes located in Europe, requires 10,000 RIPE Atlas credits. The tests in which we scheduled fewer measurements and therefore received fewer results, were obviously less expensive (280 credits for the test with probes in Africa for instance).


Appendix: Python code

The code is available at Github . It is written in Python and uses mostly standard Python libraries, which makes it very easy to use the REST API, and to parse its JSON output. The DNS reply is sent as a blob of binary data, and to parse it and extract information like the NSID, we used the excellent toolkit DNS Python .

So, to run the measurements, the core of the program is as follows:

 for area in ["WW", "West", "North-East", "South-East", "North-Central", "South-Central"]:
    data["probes"][0]["value"] = area
    request = urllib2.Request(url)
    conn = urllib2.urlopen(request, json.dumps(data))

And this is what we wrote to analyse it, after retrieving the JSON measurement result data:

 results = json.loads(open(filename).read())
for result in results:
    answer = result['result']['abuf'] + "=="
    content = base64.b64decode(answer)
    msg = dns.message.from_wire(content)
    for opt in msg.options:
       if opt.otype == dns.edns.NSID:
          ns_name =
          ns_names[ns_name].num += 1
0 You have liked this article 0 times.

You may also like

View more

About the author

Stéphane Bortzmeyer Based in Paris (France)

I work at AFNIC (the registry of .fr domain names), in the R&D department, on, among other things, DNS, security, statistics.

Comments 0