DNS Benchmark: The Only Test That Matters & How to Run It

Updated 14 November 2026 · Standard formula, shown below

The only DNS benchmark that matters measures real-world resolution time for the domains you actually visit, from your actual network, over a full day. You run it by using a tool like `dnslookup` or `namebench` (or a scripted `dig` loop) to test your current DNS server against alternatives like Cloudflare, Google, and your ISP, using a list of your most-visited domains, and repeating the test at different times. This article explains why that is the case and gives you a step-by-step method to do it correctly.

Why Most DNS Speed Tests Are Misleading

Most online DNS comparison tools query a handful of well-known domains (like google.com) from a server in a data center, not from your home or office. That tells you little about your experience. Your DNS resolver’s performance depends on several factors that a remote test cannot capture:

Network path: The route from your device to the resolver matters. A resolver with a fast global network might still be slow if your ISP routes you poorly.
Cache hit rate: A resolver that has a domain cached answers in milliseconds; a cache miss requires a recursive lookup that can take hundreds of milliseconds. Your local DNS cache also affects this.
Time of day: ISP resolvers often slow down during peak evening hours when everyone is streaming. A one-off test at noon misses that.
Your specific domains: A resolver that is fast for google.com might be slow for a niche API endpoint you use for work. The only benchmark that matters uses your own domain list.

What the Benchmark Really Measures

The only DNS benchmark that matters measures the time to get a valid answer for a query, from your device, to your chosen resolver, over a representative period. This is often called the effective resolution time and it includes:

Time to send the query (network round-trip time to the resolver).
Time for the resolver to answer from its cache (if cached).
Time for the resolver to perform a full recursive lookup (if not cached).
Time for the response to travel back to you.

It does not measure the raw processing speed of the resolver’s software. That is irrelevant to you. What matters is the wall-clock time between pressing enter in your browser and the IP address being returned.

How to Run the Benchmark Yourself (Step-by-Step)

You need a tool that can query a specific DNS server and report the time. The standard command-line tool is dig (on Linux, macOS, and Windows with BIND tools). Here is a scripted approach:

Collect your domain list: Use a browser history exporter or your router’s DNS logs to get the top 50–100 domains you actually visit. Include a mix of popular sites (google.com, youtube.com) and niche ones (your bank, your work API, a local news site).
Pick candidate resolvers: Choose 3–5: your ISP’s default (find it with ipconfig /all on Windows or scutil --dns on macOS), Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), and maybe a privacy-focused one like NextDNS.
Write a test script: For each resolver, loop through your domain list, run dig @resolver domain +noall +answer +time=2 +tries=1 and record the query time from the output. Use a tool like awk to parse the time. Repeat the loop 10 times per resolver.
Run at multiple times: Run the script at, say, 9 AM, 3 PM, and 9 PM on a weekday. This captures peak vs. off-peak performance.
Average the results: For each resolver, compute the median (not mean) of all query times. The median is robust to outliers (like a single slow packet).
Also measure cache hit rate: Run the same query twice in a row. The second should be faster. A resolver that has a high cache hit rate for your domains will feel faster in practice.

If you prefer a GUI tool, namebench (open-source, though unmaintained) automates much of this, but it uses a built-in domain list, so you may want to edit it.

How to Choose the Best Resolver From the Results

Look at the median query time and the consistency (standard deviation). A resolver with a median of 20 ms but occasional 500 ms spikes is worse than one with a steady 30 ms. Also consider:

Uptime: A resolver that is fast but has outages is useless. Check status pages for major providers.
Privacy: Some resolvers log your queries. If that matters, choose a provider with a clear no-logging policy (e.g., Quad9, Cloudflare, NextDNS).
Features: Do you need DNSSEC validation? Parental controls? Ad-blocking? These add value but may add a few milliseconds.

The winner is the one with the best combination of low median, low variance, and acceptable privacy/features for your situation. Often, the ISP resolver wins for local content (because it has a cache close to you), but a public resolver wins for global sites.

Common Mistakes That Ruin the Benchmark

Testing from a different network: Your office network and home network have different paths. Test from the network you actually use.
Not clearing your local DNS cache: If your OS caches a domain, the query never reaches the resolver. Clear it with ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (macOS) between tests.
Using a single domain: Testing only google.com is meaningless. Use a diverse list.
Testing only once: Network jitter can make a single measurement misleading. Run multiple iterations and take the median.
Ignoring the resolver’s cache: A resolver that has your domain cached will be faster. That’s a good thing, but it means you need to test many domains to get a representative mix.

Comparing Public Resolvers: What the Numbers Actually Show

In general, large public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) have excellent global infrastructure and low latency for most users. However, in some regions, the ISP’s resolver can be faster because it is physically closer to you and has a cache of popular local content. For example, a user in a small European country might find that their ISP’s resolver answers a local news site in 5 ms, while Cloudflare takes 40 ms. Conversely, for international sites, the public resolver might win because it has a better backbone connection.

Another factor is IPv6. Some resolvers handle IPv6 queries faster than others. If you have IPv6 enabled, test with both A and AAAA records. Also, some resolvers perform DNSSEC validation, which adds a tiny overhead but improves security. If you don’t need DNSSEC, you might save a few milliseconds by using a resolver that doesn’t validate (but that’s a security trade-off).

When to Re-Run the Benchmark

Your DNS performance can change over time. Re-run the benchmark:

When you change ISPs or move to a new location.
When you notice slow web browsing despite a fast internet connection.
After a major outage of your current resolver (to see if an alternative is more stable).
Every few months, because network infrastructure changes.

You don’t need to do it weekly. A quarterly check is enough for most people.

Frequently Asked Questions

Is there a single “best” DNS server for everyone?

No. The best server depends on your location, network, and the domains you visit. A benchmark on your own network is the only way to know.

Does DNS speed really affect browsing speed?

Yes, but only for the initial connection to a new domain. Once the connection is established, DNS is not used. For a page with many domains (like a news site), DNS time can add up, but the impact is usually small compared to page load time. Still, a 100 ms difference per domain can be noticeable on a page with 20 domains.

What is a good DNS resolution time?

On a typical broadband connection, a cached response should be under 10 ms. An uncached response can be 20–100 ms. If you see times above 200 ms regularly, something is wrong.

Can I use a DNS benchmark tool on my phone?

Yes, but it’s harder because you can’t easily run dig on iOS. On Android, you can use terminal emulators or apps like “DNS Benchmark” (though be cautious about permissions). The simplest way is to change your DNS server on the phone and see if browsing feels faster, but that is subjective.

Does changing my DNS server have any security risks?

If you use a reputable public resolver, the risk is low. However, any DNS server can see your queries (unless you use DNS-over-HTTPS with a trusted provider). Avoid unknown third-party resolvers. Also, ensure you use DNSSEC-validating resolvers to avoid spoofing.

Should I use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT)?

These protocols encrypt your DNS queries, preventing eavesdropping. They can slightly increase latency (because of the TLS handshake), but the security benefit often outweighs the speed loss. If you use a public resolver, enable DoH or DoT if your OS supports it. For the benchmark, test with the protocol you intend to use in practice.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.