There are about 600 DNS root server instances deployed around the world. But does everyone have an equal level of access to a root server in their region? Are they fairly distributed? Do all major (and country level) network operators recognise the value in deploying (or peering with) a root server in their network?
The RIPE NCC operates K-root in multiple locations around the world, many of them in Europe and the Middle East. The people behind this service are doing an amazing job of keeping K-root accessible. There are several K-root nodes  hosted by local network operators to improve the user experience.
Figure 1: K-root nodes in Europe and the Middle East (see interactive map )
Given the current state of Internet connectivity in the Middle East, I thought it would be interesting to measure response times from K-root throughout countries in the Middle East using the RIPE Atlas infrastructure. RIPE Atlas provides a friendly API so you can run custom measurements using probes that are deployed by various hosts. Using the API, I put together a quick python script to measure DNS response times, as well as a traceroute to K-root servers, using probes installed in Middle Eastern countries. 
The script creates measurements for DNS response times (querying NS records for the .com zone) as well as traceroutes for up to 50 probes per country. It then fetches the results in JSON format and prints them in CSV, so you can use it in your favourite spreadsheet or graphing application for further analysis.
The initial result for DNS query response times shows that there is huge variation in the results in different countries:
Figure 2: Average RTT to K-root per country in the Middle East
Iran's average of 25ms is the lowest delay, with 49 probes out of 50 responding to my request. There are two K-root nodes hosted in Iran and it seems the networks have good connectivity to those nodes. Turkey's RTT of 66ms is more than double that of Iran , with 28 live probes in the country. While there seems to be no K-root nodes deployed in Turkey, the network operators are very well connected and provide good access to the service. At the other end of the graph, Oman displays 581ms. However, there was only one probe available in Oman, but several queries yielded almost the same result. If we disregard Oman (due to the low number of RIPE Atlas probes in the country), Iraq shows the highest delay, with an average of 193ms and 7 probes responding. Given this high RTT, it seems networks in Iraq have poor connectivity with other countries in the region.
Analysing traceroute data to determine the number of hops between RIPE Atlas probes and K-root, the results were quite different.
Figure 3: Number of hops to K-root per country in the Middle East
When we look at hop counts, Qatar has the fewest with seven, while Syria, Lebanon and Palestine each have 11 hops (with a total of 21 probes responding). The data suggests that K-root connectivity in the west of this region is poorer compared to other areas. The RIPE NCC might consider deploying a K-root node in that area to improve the connectivity. The hop count might not be an acceptable sort of measurement for connection quality, but the data shows there is no available node close to those countries.
I also performed the same set of measurements for countries in Central Asia that are in the RIPE NCC service region. There were more probes available in these countries, which resulted in more reliable statistics.
Figure 4 shows the average RTT for countries in Central Asia.
Figure 4: Average RTT to K-root per country in Central Asia
As you can see in the graph above, Armenia has the lowest response delay with an average of 34ms (data gathered from 19 probes). Ukraine has an average of 40ms response time from K-root (data from 50 probes in the country). The countries showing the highest response delay are Uzbekistan and Kazakhstan (both on the eastern edge of the region) with an average of 131ms and 101ms respectively (a total of 28 probes responded in these countries).
Looking at the traceroute graph, we observe a similar pattern:
Figure 5: Number of hops to K-root per country in Central Asia
Armenia is the lowest again, with an amazing average of 4 hops distance to the root server. Given the fact that a K-root node is already hosted in Yerevan, it seems that local operators have very good local connectivity to K-root. At the same time, Uzbekistan and Tajikistan are at the other end of the graph with 14 and 13 hops distance respectively. Another surprising data point is Kazakhstan with an average of 9 hops distance, given the fact that there are two instances of K-root are locally hosted in the country.
This was only an example of an analysis that can be carried out based on RIPE Atlas probes and data. You can simply develop your own scripts to run almost any analysis on this gold mine of measurement data.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Shane Kerr •
It would be interesting to see a comparison of K root times versus access to sites hosted nearby each of the Atlas probes, to try to see how much of the RTT is due to the probe's connection to it's ISP and how much is due to the actual path to the K root instance.
Hide one reply
Babak Farrokhi •
I already excluded the probes that were not directly connected to their country infrastructure (e.g. Satellite links) based on the traceroute results. I also repeated the tests to make sure temporary failures are not affecting the results. However some inaccuracies in results cannot be ruled out. This is why I used as many probes as available in each area to minimize the errors.
Note that some Probes may be incorrectly labeled as being in .ps when they're actually in Israel (and possibly vice versa). I noticed that on mine and changed the location on the map so the country label is accurate, but I don't know if there are any other Probes that may be in a similar situation but with hosts that either didn't notice or just don't care.
Babak Farrokhi •
Thanks for the note. Probes seems to be labeled based on MaxMind GeoIP which is not 100% accurate, given the recent IPv4 transfer wave and other factors. However Atlas owners usually fix this CC mismatch manually, like you did.