Things to look for in comparing recursive DNS servers performance:<p>The 95%ile DNS response time for cached/uncached names. The 95%ile DNS response when one/some of the authoritative nameservers is "lame" or not responding. (better yet, 99%ile, but that requires even more queries...)<p>The average packet loss to the nameserver. (As many resolvers use the default of a 5s timeout, better resolvers use a 1s timeout, the best stub resolvers would use a dynamic timeout, but afaik, none do...).<p>Do they implement DNSSEC validation? What is their story for domains that break DNSSEC (eg: <a href="https://www.internetsociety.org/resources/deploy360/2014/case-study-comcasts-dnssec-implementation/" rel="nofollow">https://www.internetsociety.org/resources/deploy360/2014/cas...</a>)?<p>Do they implement RFC7129 (authenticated denial of existence)? This can be used to prevent your service being used to attack an authoritative nameserver, prevents leaks of useless domains (eg machines looking up untitled.pdf as a domain), and allows you to return NXDOMAIN with much lower latency, making DNS search paths faster. RFC8020 (NXDOMAIN: There is really nothing underneath) would be another example where you can prevent leaking names, and return faster responses from a smaller cache (although I admit I've never seen anyone implement RFC8020 yet).<p>Will they accept (signed) responses into their cache in the additional section? Again, this can significantly reduce the time for uncached responses.<p>[hint: These are good reasons you should sign your domain, it can make things faster and reduce load on your authoritative nameserver!]<p>What is their story for domains that need a cache flush?<p>Do they (correctly) implement IPv6 from the recursive to the authoritative nameservers? Do they (correctly) implement IPv6 from the stub to the recursive nameserver?<p>How big is their cache? How long do things stay in their cache? There's no point being close to a nameserver with an empty cache. Querying www.google.com isn't really going to tell you much about their cache depth, nor is the Alexa 1M. You need a very very wide variety of names.<p>Do they provide good GeoIP responses? There's no point in getting an answer for the middle of the US in <1ms if you happen to be 300ms away in Asia somewhere. The DNS response was fast, but the webserver it sent you to is going to give you abysmal performance. This is often done with EDNS0-Client-Subnet, but it can also be fudged by making the outbound IPs for the iterative requests being diverse enough for different localities.<p>Do they "lie" about names? In what circumstances do they lie? Do they NXDOMAIN malicious domains? adult websites? ad domains? random websites? Do they redirect ad websites to their own ad farm? How do their lies handle DNSSEC?<p>Do they perform QNAME minimalisation to help protect your queries from servers that don't need it?<p>What other features do they implement to make sure their cache is never poisoned?<p>What is their abuse plan? If I send them a vast number of queries what happens? Do they send back TrunCated responses and force me over TCP? Will they respond with SERVFAIL? Or will they drop the queries? Or will they pass them all through to the authoritative nameservers? Do I need to do anything (other than stop sending abusive amounts of load) to be unblocked? What if the reason I'm sending a large number of queries is because I'm a carrier grade NAT IP pool and I have one broken/bad user?<p>What is their reliability story? Is it expected that they will go down for 10 minutes every now and again?<p>What do they do about general Internet Hygiene? Do they have protects against being used for reflection attacks?<p>Do they do preemptive lookups to keep their cache warm or is someone always guaranteed to have to wait for the full resolution? How do they make sure they don't accidentally DoS authoritative nameservers with preemptive resolutions?<p>Things not to look for:<p>ICMP/mtr times are essentially meaningless, except as providing general information about routing decisions.<p>The mean response time, as it tends to be washed out by cached response times, and what you don't care about is if it takes 15ms or 17ms on average, as you can't perceive the difference. What you _do_ care about is if one nameserver has 1/5000 queries which take >1s as that will become a frequent noticeable problem when your surfing.<p>Just looking at a few common names that are likely to be in the cache. Yes, those are important, but as with anything at scale, it's the long tail that's actually interesting and will dominate your perception of performance. You can set up your own domain, and search for random strings and force the full end-to-end query flow. (Beware about wildcard domains for this, if your domain is signed, in theory the nameserver could synthesize responses without going back to your nameserver).<p>Where are your vantage points for measurements? Many people appear to measure from places like AWS zones, and then report spectacular performance for DNS servers also hosted in the same AWS zones – despite most of their users not being hosted there.<p>Hmm, I'm sure there's more, but that's off the top of my head.<p>(Disclaimer: Once upon a time, I was one of the engineers oncall for Google Public DNS, so I have Opinions)