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  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.
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.
We have released a technical report with our detailed findings. The report is publically available at this site.
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 http://traces.simpleweb.org/ and at https://ant.isi.edu/datasets/.
 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.
 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