Recursives in the wild: engineering authoritative DNS servers

The Domain Name System (DNS) is a critical part of the internet infrastructure and maps domain names to IP addresses in a distributed way. DNS queries can form a noticeable part of web latency [1], which is why we investigated how DNS operators like SIDN are able to reduce DNS response times.

Data analysis

We currently run 8 separate servers for .nl, of which 5 are unicast and 3 use anycast across more than 80 sites. Recursive resolvers can choose from any of the 8 servers to send their queries to. Previous research [2] has shown that the recursive resolvers have different strategies for selecting a name server. Some take the round trip time (RTT) of a server into account, others choose a server randomly. However, they did not estimate how prevalent these strategies are on the internet.Therefore, we ran our own measurement with 9000 RIPE Atlas probes querying a test domain, using 7 different name server setups with up to 4 servers spread across the world.

Key findings

We discovered that the up to 69% of recursive resolvers send the majority of queries to the fastest responding name server. However, there is always a share of queries that are sent to the slower responding authoritative as well. Also, in some scenarios, 41% of recursive resolvers do not prefer the fastest responding authoritative. This can increase the reliability and security, but also has the consequence that still many queries are not served as quickly as possible.


That observation led us to the conclusion that DNS operators should not rely on the selection strategies of recursive resolvers but should actively optimise their own set-ups to decrease the response times. For example, a request from a recursive resolver in the U.S. to a unicast name server located in the Netherlands will always take at least 70 ms to be answered, due to the sheer distance between the two continents. However, from our measurements we now know that recursive resolvers in the U.S. will still send a significant share of their queries to this authoritative, despite the fact that there are authoritatives in the same country.Thus, we recommend that all of a DNS operator's name servers should be deployed as an anycast service, with sites equally spread across the world. With a set-up like that, it does not matter which name server a recursive selects. The routing protocol BGP will (hopefully) make sure that it gets directed to a name server site nearby, which can answer the query as fast as possible.

Use for .nl

We discussed our finding with our operations team and recommended phasing out our unicast name servers and replacing at least some of them with well-connected anycast name servers. We will keep our readers posted about further developments.

Technical report

We have released a technical report with our detailed findings. The report is publically available at this site.

Joint work

The technical report has been produced jointly by Moritz Müller (SIDN Labs), Giovane C. M. Moura (SIDN Labs), Ricardo de O. Schmidt (University of Twente), and John Heidemann (USC/ISI). The datasets underpinning the paper were measured with RIPE Atlas and are available at and at


[1] A. Singla, B. Chandrasekaran, P. Godfrey, and B. Maggs. The internet at the speed of light. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks, pages 1–7. ACM, Oct. 2014.[2] Y. Yu, D. Wessels, M. Larson, and L. Zhang. Authority Server Selection in DNS Caching Resolvers. SIGCOMM Computer Communication Review, 42(2):80–86, Mar. 2012.



Moritz Müller

Research engineer

+31 26 352 55 00

  • Monday 29 January 2018


    New blood for our New Business Department


    "You've got the opportunity here to introduce propositions that really add value."

    Read more
  • Thursday 29 March 2018


    News media have work to do


    When it comes to domain name security, the news media are not doing well.

    Read more
  • Monday 25 March 2019


    A world where language isn't a barrier


    Travis Foundation digitises languages to facilitate integration

    Read more


Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.