You are here: Home > Publications > RIPE Labs > JH Kuipers > Analysing the K-root Anycast Infrastructure

Analysing the K-root Anycast Infrastructure

JH Kuipers — 27 Jul 2015
Anycast is used by most of the DNS root-servers and other services like Cloudflare. It provides localisation and scaling benefits to clients using the anycasted service. An anycast service uses one IP for several instances of the same service. The routing system is then responsible for directing a client to the closest instance of the service. In theory, a client should always reach the closest instance, but it turns out that this is not always the case. At the DACS group of the University of Twente, we analysed the anycast infrastructure of K-root and tried to find how many clients reached the closest instance.

 

The K-root name server is in constant expansion. At the time of this research, however, K-root had 20 server instances located around the world. All instances are reachable via the anycast IP-address and also through a unicast IP-address (one machine per IP). To perform the measurements, we had to decide which strategy to use. We could make use of a passive strategy, using logs to check which client IP-addresses connect to each K-root instance and then map those IP-addresses to locations. We have chosen, however, an active approach, using RIPE Atlas to probe K-root from different locations worldwide.

This active strategy provides more information about the probe locations than a (possibly inaccurate) IP-to-location mapping using Geo-IP databases. Among other things, the RIPE Atlas measurement framework provides a city-level accurate location of its probes.  We performed measurements in countries split into three groups, based on the following criteria:

  • Group 1 : Countries with a local K-root instance. This group of countries is interesting because probes from that country might bypass the local K-root instance, which would probably result in a non-optimal Round Trip Time ( RTT ) for DNS queries.
  • Group 2 : Countries with a large share of Internet users and a large number of available probes. These countries could ensure the availability of a large number of probes in the measurements.
  • Group 3 : Countries from continents not yet represented by the previous two groups. Each continent had at least three countries in the total country selection. 

The actual probing consisted of a two step process. The first step was determining which K-root instance a probe was directed to. This was done using a special DNS-query which reveals the name of the queried K-root instance. The second step was to measure the RTT to all K-root instances in order to determine which of the K-root instances was the actual "closest" one to the probe. Both the RTT and location of the K-root instance reached by a probe can be compared to the location and RTT of the other probes to determine whether a probe chose the optimal instance or not.

Having the results from all probes, we could then group the probes and compare results for different sets of probes. One of our results is shown in the map below, where each marker represents a used probe from RIPE Atlas. The colour code is as follows:

  • Green probes were directed to the closest K-root instance in terms of both RTT and geographical distance
  • Red probes did not reach the closest K-root instance either topologically or geographically
  • Blue probes reached the closest K-root instance geographically
  • Yellow probes reached the closest node only in terms of RTT

The letters on each marker indicate which K-root instance the probes reached. Furthermore, the location of K-root instances are represented by brown markers.

K-root anycast probes map

Quantifying the results from the map above, the pie chart below shows the percentages of probes that reached the closest instance. Surprisingly, only half of the probes in our measurement reached the closest instance at least in terms of latency (RTT).

K-root anycast percentage pie

Our results might help operators of anycast services to identify areas in which their infrastructure can be further improved. We are working on extending this research by including more probes in a new and longer measurement period. In addition, we plan to perform the same study with other root-level servers.

Some of the the RIPE Atlas measurement IDs used are listed below:

2021566
2021565
2021564
2021563
2021562
2021561
2021560
2021559
2021558
2021557
2021556
2021555
2021554
2021553
2021552
2021550
2021549
2021548
2021547 

0 Comments

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.