How to Benchmark DNS Resolvers

Why Benchmark Instead of Trusting a List

Before your browser can load any site, it must turn a domain name into an IP address — a DNS lookup. The time that lookup takes is added to the start of every connection to a new domain, so a slow resolver makes the whole web feel sluggish even when your bandwidth is fine. "Fastest DNS" lists are averages across the world; the resolver nearest to your ISP's network, with the best route from your home, is what actually wins for you. The only way to know is to measure from your own connection.

The Core Measurement: dig and nslookup

The dig command reports a Query time in milliseconds — exactly the number you want. You point it at a resolver with @ and ask for a domain.

# macOS / Linux — query a specific resolver and read "Query time"
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
dig @9.9.9.9 example.com

# Look for a line like:  ;; Query time: 23 msec

# Windows (nslookup has no timer; use Measure-Command in PowerShell)
Measure-Command { nslookup example.com 1.1.1.1 }
# read the TotalMilliseconds value

The popular public resolvers to compare are Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), plus your ISP's own resolver (shown in your router status page). Always include your ISP's resolver — it is often the fastest because it lives inside your provider's network, and sometimes the slowest, which is the whole reason to test.

The Caching Trap — Measure Uncached Queries

This is the mistake that ruins most DNS benchmarks. The first time a resolver looks up a domain it does the full work and reports a real time. Every lookup after that is served instantly from its cache, so the second run of the same domain looks blazing fast on every resolver — telling you nothing. To compare fairly, query domains the resolver is unlikely to have cached, and use a fresh domain for each run:

# Query several different, less-common domains rather than the same one twice
for d in wikipedia.org github.com bbc.co.uk reddit.com nasa.gov; do
  echo -n "$d via 1.1.1.1: "; dig @1.1.1.1 $d | awk '/Query time/{print $4" ms"}'
done

Run the same loop against each resolver, then compare the averages — not any single number. One slow outlier (a domain whose authoritative server was far away) should not decide the winner.

Reading the Results

Cached lookups will be a few milliseconds on any resolver, so ignore those for comparison. Judge resolvers purely on their uncached average, because that is the delay you feel when you open a site you have not visited recently.

Beyond Raw Speed

Speed is not the only axis. Weigh these alongside your benchmark before switching:

• Consistency — a resolver that averages 40 ms but occasionally spikes to 300 ms feels worse than a steady 55 ms. Run enough queries to see the spread, not just the mean.
• Reliability — a resolver that is fast but occasionally fails to answer will cause "site not found" errors. The major public resolvers are highly reliable; very small or free novelty resolvers may not be.
• Features — some resolvers add malware blocking (Quad9), family filtering, or DNS-over-HTTPS encryption. Those can be worth a few milliseconds.

Once you have a winner, set it on your router so every device benefits, or per-device if you prefer — see how to change your DNS server. For curated starting points, the fastest DNS servers and public DNS servers compared guides list the main options.

When DNS Is the Actual Problem

Benchmarking assumes DNS is merely slow. If sites fail to load entirely, or only some sites resolve, you may have a DNS fault rather than a speed difference — in that case start with verifying DNS is the problem before optimising which resolver is fastest.

Frequently Asked Questions

Does a faster DNS resolver make my internet faster?

It does not increase your bandwidth, but it can make websites feel snappier. DNS resolution happens before any page can load, so shaving 30–80 ms off every first lookup to a new domain makes browsing feel more responsive — especially on pages that pull resources from many domains. It will not change your speed test download number.

Why do my benchmark numbers vary so much between runs?

Caching is the main reason. The first lookup of a domain is resolved from scratch and is slow; every lookup after that is served from cache in a millisecond or two. To compare resolvers fairly you must query domains that are not already cached, or clear the cache between tests, and average many queries rather than trusting a single result.

What is a good DNS resolution time?

For an uncached query, anything under about 30 ms is excellent, 30–80 ms is good, and consistently over 120 ms is worth changing. Cached queries should be near-instant at a few milliseconds regardless of resolver. The number that matters for the feel of browsing is the uncached time, because that is the delay you hit when visiting a new domain.

Should I just use my ISP's DNS?

Sometimes it is the best choice — it sits inside your provider's network, so it is often the lowest-latency option. But ISP resolvers vary widely in quality, some log or monetise your lookups, and some are slow or unreliable. Benchmark it against the major public resolvers; if it wins on speed and you trust it, keep it, otherwise switch.