DNS Benchmark

Find the fastest DNS server for your location with cache-free recursive resolution testing.

DNS Benchmark measures the real-world performance of multiple DNS resolvers simultaneously. Unlike most benchmarking tools, it queries hundreds of unique random subdomains that no resolver has ever seen before, forcing a full recursive lookup every time. The result is an accurate, apples-to-apples comparison of how fast each server actually resolves new names.

This matters because popular resolvers almost always have well-known domains like google.com cached in memory. Testing with those tells you how fast the server reads from cache, not how fast it works. DNS Benchmark sidesteps that entirely.

🚫

Cache-Free Testing

Every query targets a unique random subdomain that no resolver has ever seen. Each one triggers a full recursive lookup through root, TLD, and authoritative nameservers, reflecting exactly what happens when a user visits a site for the first time.

🔄

Interleaved Rotation

Rather than testing each server in sequence, DNS Benchmark rotates queries across all servers in round-robin order. Every server experiences the same network conditions at the same point in time, so the comparison is genuinely fair.

🛡️

Rate-Limit Protection

A configurable random delay between queries distributes the load naturally, avoiding patterns that might trigger DoS detection on the servers under test. Fast mode is available for throughput testing when you don’t need that protection.

📊

Ranked Results

Servers are sorted fastest-first with the winner clearly labelled. Failed queries are counted and reported separately per server so they don’t silently skew averages.

How to Use It

Download the binary for your platform, make it executable if needed, then pass the DNS server IPs you want to test as arguments:

dns-benchmark [flags] <DNS_SERVER_1> <DNS_SERVER_2> ...

Compare Cloudflare, Google, and Quad9 with the defaults:

dns-benchmark 1.1.1.1 8.8.8.8 9.9.9.9

Use a higher query count for a more statistically reliable result:

dns-benchmark -count 200 1.1.1.1 8.8.8.8 9.9.9.9

Run in fast mode to test raw throughput with no inter-query delays:

dns-benchmark -fast 1.1.1.1 8.8.8.8

Use your own domain with a wildcard A record so queries return a real IP rather than NXDOMAIN:

dns-benchmark -domain test.yourdomain.com 1.1.1.1 8.8.8.8

Flags

Flag	Default	Description
`-domain`	`dns.neterix.info`	Base domain for random subdomain queries. A wildcard A record (`*.domain`) is recommended so queries return a real IP rather than NXDOMAIN.
`-count`	`500`	Number of unique random subdomains to query per server. Higher values give more statistically reliable averages.
`-timeout`	`5s`	Per-query timeout. Queries that exceed this are counted as errors.
`-delay`	`50ms`	Maximum random delay between queries. The actual delay is a random value between 0 and this ceiling, which distributes load naturally.
`-fast`	`false`	Disables all inter-query delays. Useful for throughput testing. Overrides `-delay`.

Sample Output

Testing 3 server(s) with 200 unique random subdomain queries each against test.yourdomain.com (max delay: 50ms, interleaved)

Warming up DNS servers...
Warm-up complete.

Progress: 600/600 queries complete...

--- Results (fastest first) ---
1. 1.1.1.1: 18.43 ms (fastest)
2. 9.9.9.9: 24.71 ms
3. 8.8.8.8: 31.06 ms

Notes

For best results, configure a wildcard A record (*.yourdomain.com) on a domain you control and pass it with -domain. This ensures every random subdomain resolves to a real IP, making the test indistinguishable from legitimate browsing traffic.
The default test domain (dns.neterix.info) has a wildcard record configured, so the tool works out of the box without any domain setup.
Increasing -count reduces the effect of random variation. 500 queries is the default; 200 is usually sufficient for a quick comparison.
Use -fast only when you want to measure raw throughput. In normal use the delay keeps the test polite toward the servers under test.
Each server receives one warm-up query before timing begins, so cold-start latency doesn’t penalise the first result.