Reaching AuthDNS - A RIPE Atlas Analysis by Region

As the name suggests, root name servers serve DNS root zones. But caching DNS resolvers also need to query servers of other important zones, such as when resolving reverse DNS queries, or looking up services provided by the RIPE NCC and the other Regional Internet Registries (RIRs). These other zones are served by the RIPE NCC’s AuthDNS service.

To list them in full, here are all the zones served by the AuthDNS cluster:

• in-addr.arpa and ip6.arpa, and their related zones
• ripe.net, as well as the zones of all the other Regional Internet Registries (RIRs)
• Zones of organisations supported by RIPE NCC, such as MENOG (menog.org) and the NRO (nro.org)
• Reverse DNS zones corresponding to the IP address space allocated to the RIPE NCC
• Reverse DNS zones corresponding to the IP address space allocated to the other RIRs
• Zones of some smaller Country Code Top Level Domains (ccTLDs)
• Infrastructure zones, such as as112.net and root-servers.org

Current infrastructure

The RIPE NCC operates AuthDNS across four core sites: in Amsterdam, London, Stockholm, and Tokyo. Each of these sites has networking equipment to handle routing and clusters of servers to handle the DNS queries. They are also each connected to one or more important Internet Exchange Points (IXPs) so as to provide as much availability as possible.

In addition to these core sites, we also operate hosted DNS instances. These are single instances of the service, running on Dell servers or virtual servers, hosted by Internet Service Providers or IXPs. The hosts provide the server and connectivity and the RIPE NCC installs, configures and operates the service. Currently, there are 20 such instances in various locations around the world.

Why are hosted AuthDNS instances important?

Some services on the Internet, like email delivery and SSH logins, need to look up PTR records (reverse DNS records) of the IP addresses that are connecting to them. They issue queries to their local caching DNS resolver, which then needs to lookup zones such as in-addr.apra or ip6.arpa and their child zones.

The faster these queries succeed, the faster the client can connect to the email server or SSH server. This is where having a RIPE NCC AuthDNS instance close to the caching DNS resolver comes in handy, as less distance means faster lookups for these queries. Of course, 'close' according to BGP, which determines how packets are routed across the Internet, and 'geographically close' aren't always the same thing. But having an AuthDNS instance in a region means shorter routes become available for DNS queries originating in that region.

Measuring DNS queries to AuthDNS with RIPE Atlas

This year, we decided to adopt a more scientific approach to our strategy for increasing the number of AuthDNS instances. To this end, we took three regions that are known to be less well covered by some of the RIPE NCC data and measurement services - i.e., South East Europe, Central Asia, and the Middle East - and ran measurements from RIPE Atlas probes in these regions towards AuthDNS.

By looking at the results of these measurements, our aim is to get a clearer picture of what DNS queries to AuthDNS get routed to, what latencies are encountered, and ultimately, where there's a need for new hosted instances of AuthDNS.

SEE

With the SEE meeting being held in April, we thought to start with the analysis of the South East Europe countries. We set up a measurement for all active RIPE Atlas probes in SEE. The measurement was designed to query the AuthDNS server (193.0.9.7) for 150.6.0.193.in-addr.arpa every 30 minutes and to record the id of the name server that responded. In post processing, the data per probe per day was then aggregated so as to give the number of measurements, the server reached, and the median response time.

Figure 1 shows the total number of valid measurement results each day (no timeouts), while the different colours represent the number of measurements that got an answer from an AuthDNS node in the respective cities.

The big picture was fairly stable for the 6 week period over which we ran the measurements. The only big change is that after 22 April we no longer saw probes getting an answer from Vienna (Wien). This was the result of the node being under maintenance in that period. The graph suggests that probes switched to Salzburg and Amsterdam instead.

Figure 2 splits the data across countries. The length of each bar represents the total number of measurements in a country, while the colour indicates which fraction reached a specific AuthDNS node. Lastly, the numbers in/next to the bar tell you how many probes got answers from each node.

As you can see, many of the SEE probes reach an AuthDNS node in Amsterdam. In Bosnia and Herzegovina and (especially) in Romania the majority of probes reach the local node. That's a good sign. However, we also have probes that consistently choose an AuthDNS in the US (Kansas City) or Bahrain (Manamah), which is of course sub-optimal due to the larger round trip times (RTTs).

Central Asia

Prior to the CAPIF 3 meeting this September, we started running measurements for the countries in Central Asia where there were RIPE Atlas probes available. As there are no AuthDNS instances in the region, we wanted to get a clearer view of where the DNS queries go. As we can see from figure 3, the results are rather stable with most of the queries being answered by the AuthDNS instance in Amsterdam or Stockholm.

Again, in Figure 4, we see this broken down per country.

Figure 5 shows for each day what the median round trip time was for each probe coloured by responding AuthDNS server. We can see that most days most probes have a median below 120s, but there are always some with higher latencies. The graph also shows that probes which reach Stockholm typically have lower latencies than those reaching Amsterdam.

We wanted to take one single day from these results and shows how many results we have at particular RTTs. As well as providing more insight into the distribution over probes, Figure 6 makes it clear that results from Amsterdam with RTT of 90-100 ms are more common than results with 80-90ms.

Middle East

Ahead of the MENOG 24 meeting in Oman, we started performing measurements from probes in the surrounding region. The results of these measurements, conducted over a three-week period, show some interesting choices made in the routing system. Although we have an AuthDNS node in Manama, Bahrain, most probes ended up querying a more remote instance. These were predominantly instances in Europe, but we also observed probes that went as far away as Maracaibo in Venezuela or the island of Guam in the Pacific.

After observing a more-or-less similar distribution of the instances reached for 21 days, the instance in Vienna suddenly disappeared from the measurement results on 25 November. This caused a shift in result distribution, with more probes reaching Stockholm and Maracaiabo, as well as the (for this measurement) new choice of Bucarest, Romania.

When we look at the distribution per county, we see how almost all probes in Iran queried the AuthDNS in Vienna on 19 November, but had switched to other places by 26 November.

Although we have an AuthDNS node in Bahrain, hosted by STC Bahrain, this instance is predominantly used by probes in Saudi Arabia. When we break down the results by the ASNs in which the probes reside, we see how probes in Bahrain’s Batelco (AS5416) hardly ever reached the instance in geographically nearby STC Bahrain.

In Saudi Arabia, however, AS25019 (Saudi Telecom Company) reached out to the AuthDNS instance in STC Bahrain during the entire measurement period. As both the probe host and the AuthDNS host are part of STC-Group, we can understand how, given the choice, AS25019 prefers routes to its sibling in Bahrain over routes to other AuthDNS instances.

From a performance point of view, Bahrain is also the best choice for Saudi Arabia. The median RTTs from probes in the country to the instance in Bahrain are well below 50ms, where probes that reach AuthDNS instances in Europe record RTTs around 100ms. The probes which queried the very distant AuthDNS in Venezuela and Guam understandably experienced the worst RTTs of typically 220ms and 320ms respectively.

Conclusion

Which AuthDNS instance a given query will be directed to will always depend to a large extent on which routing decisions have been made, which peering relationships established, and so on. And one thing that the above analysis has shown is that such factors can sometimes conspire to bring about unexpected outcomes.

But even with those factors in place, achieving a better distribution of AuthDNS instances across different regions - and so bringing AuthDNS closer to local organisations - can be a very effective way to reduce latencies and improve DNS resolution for these important zones. Getting more organisations in a region to host new AuthDNS instances is one of the best ways to increase the likelihood that local DNS queries will be resolved locally, avoiding some of the long, out-of-region journeys we saw in the above analysis.

The RIPE NCC is therefore seeking hosts who are willing to provide the resources for this service. By partnering with us, organisations can play a role in reducing latencies for their customers, their sibling organisations, and their regions as a whole. If you're reading this and you're interested in applying, you can do so here: https://hosted-dns.ripe.net/