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

Introduction

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 d.nic.fr , an anycast name server managed by AFNIC . It is used, among other things, for the TLD " .fr ". The d.nic.fr name server has NSID enabled as you can see with ' dig +nsid @d.nic.fr 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 d.nic.fr 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.

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

Two name servers stand out: one in Paris, dns.th2.nic.fr and one in Frankfurt, dns.fra.nic.fr . Note that this does not measure their actual traffic, but the size of the BGP attraction basin: one third of the probes have dns.th2.nic.fr 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 d.nic.fr . 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 dns.bru.nic.fr (in Brussels) no longer appears which means none of the RIPE Atlas probes connected to this instance.

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.

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).

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

Africa and Russia are the only areas where dns.th2.nic.fr 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:

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

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

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

Note that, as a sampling effect, some instances of d.nic.fr , such as dns.run.nic.fr (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.

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.

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

Conclusions

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 = opt.data
 

           ns_names[ns_name].num += 1