DNS performance is critical for any network infrastructure. Whether you’re managing a public resolver, running a caching forwarder like Unbound or dnsmasq, or operating a high-volume recursive DNS service, you need reliable metrics to validate your setup.

dnsperf is the industry-standard benchmarking tool created by DNS-OARC. It measures query throughput, latency, and stability under realistic or even unrealistic 🙂 load conditions, giving you the data you need to optimize your DNS infrastructure.

This guide walks you through:

• Installing dnsperf
  
• Preparing query files
  
• Running benchmarks
  
• Understanding your results
  
• Sample expected performance numbers
  

---

1. What Is dnsperf?

dnsperf is a specialized DNS load testing tool that simulates high-volume query traffic to measure server performance. It sends DNS queries at maximum sustainable rates while tracking:

• Queries per second (QPS) – Total throughput capacity
• Response latency – How quickly queries are answered
• Packet loss and timeouts – Reliability under load
• Server stability – Sustained performance over time

DNS operators, ISPs, and infrastructure engineers rely on dnsperf to validate server capacity, optimize configurations, and plan for growth.

---

2. How to Install dnsperf

Debian/Ubuntu Installation

The simplest installation method uses your distribution’s package manager:

sudo apt update
sudo apt install -y dnsperf

If dnsperf isn’t available in your repositories, you can compile it directly:

sudo apt install -y build-essential libssl-dev libbind-dev libkrb5-dev libcap-dev libxml2-dev git

git clone https://github.com/DNS-OARC/dnsperf.git
cd dnsperf
./autogen.sh
./configure
make -j$(nproc)
sudo make install

Verify the installation:

dnsperf -h

You should see the help output with available options and usage examples.

---

3. Creating a Query File for Testing

dnsperf requires a query file formatted like:

<domain>. <type>

Each line represents one DNS query. The tool loops through this file continuously during benchmarking.

Examples:

google.com. A
facebook.com. AAAA
cloudflare.com. MX
8.8.8.8.in-addr.arpa. PTR

Quick Start: 25-Domain Test File

Here’s a basic query file covering common record types and real-world domains. Save this as /tmp/dnsperf-test.txt

Sample Domain List (25 Entries)

google.com. A
facebook.com. A
youtube.com. A
openai.com. A
cloudflare.com. A
microsoft.com. AAAA
amazon.com. A
reddit.com. A
github.com. A
gitlab.com. A
netflix.com. A
cnn.com. A
bbc.co.uk. A
wikipedia.org. A
mozilla.org. A
stripe.com. MX
paypal.com. MX
airbnb.com. A
booking.com. A
oracle.com. AAAA
8.8.8.8.in-addr.arpa. PTR
1.1.1.1.in-addr.arpa. PTR
example.com. A
test12345.example999.com. A
nonexistent-domain-abc123.com. A

This list includes:

• Popular domains with expected NOERROR responses
• Different record types (A, AAAA, MX, PTR)
• Non-existent domains to test NXDOMAIN handling

dnsperf will loop through this file repeatedly for sustained benchmarking.

Production-Grade Testing: 100,000 Domain List

For realistic benchmarking that mirrors production traffic patterns, a small query file won’t cut it. With only 25 domains, your resolver’s cache hit ratio will be artificially high, making forwarding resolvers appear faster than they actually are under real-world conditions.

We’ve compiled a comprehensive list of 100,000 real-world domains specifically designed for DNS benchmarking:

Download 100K Domain List

Why Use a Large Domain List?

• Realistic cache behavior – Simulates actual hit/miss ratios seen in production
• Accurate forwarding tests – Prevents cache from skewing results
• Better recursion testing – Forces real upstream queries instead of cached responses
• Diverse query patterns – Includes various TLDs, domain structures, and popularity distributions
• Statistical significance – Provides enough data points for meaningful performance metrics

Using the 100K List

Once downloaded, use it exactly like the smaller test file:

bash

dnsperf -s 192.168.1.10 -d /path/to/100k-domains.txt -l 60

For production validation, the 100K list is essential. It reveals how your resolver performs when caching is less effective, the scenario that matters most for capacity planning.

---

4. Running dnsperf

Basic command

The standard dnsperf syntax is straightforward:

dnsperf -s <DNS-SERVER-IP> -d <QUERY-FILE> -l <SECONDS>

Example: 30-second test against local resolver

dnsperf -s 192.168.1.10 -d /tmp/dnsperf-test.txt -l 30

This command:

• Sends queries as fast as the server can handle them
• Runs for 30 seconds
• Uses UDP (default protocol)
• Reports comprehensive performance statistics

---

Test a DNS server on a non-standard port  (54 in this case)

dnsperf -s 176.9.21.94 -p 54 -d /tmp/dnsperf-test.txt -l 30

---

Run with TCP instead of UDP

dnsperf -s 176.9.21.94 -d /tmp/dnsperf-test.txt -t -l 30

TCP tests are important because:

• Some queries exceed UDP packet size limits
• TCP provides guaranteed delivery
• Performance differs significantly from UDP

---

5. Example Output and Interpretation

A typical dnsperf output looks like this:

Queries sent:         2,338,151
Queries completed:    2,337,872 (99.99%)
Queries lost:         279 (0.01%)

Response codes:       NOERROR 2,337,872 (100%)
Run time (s):         30.000775
Queries per second:   77,927.05

Average Latency (s):  0.000701 (0.7 ms)
Latency StdDev (s):   0.000544

How to interpret results:

Metric	Meaning
QPS (Queries per second)	How many queries your server can handle in steady load
Completion %	Should be 99.5%+ for healthy resolvers
Avg Latency	<7ms is excellent; ~40ms performance starts to feel slow
Timeouts	Should be <0.1%
Response codes	Mainly NOERROR for valid domains

---

6. What Is Considered “Good” Performance?

DNS performance depends heavily on:

• CPU cores and frequency
  
• Whether resolver is recursive or just forwarding
  
• Cache hit ratio
  
• Network link to upstream resolvers
  

But as general guidance:

🚀 Forwarding Resolver (Unbound, dnsmasq)

On a modern Xeon CPU:

• 50,000 – 100,000 QPS = Excellent
  
• ~10-20 ms latency = Very good
  
• >99.9% completion = Very healthy
  

🔍 Full Recursive Resolver (Unbound/BIND full recursion)

• 10,000 – 40,000 QPS depending on caching
  
• Latency increases due to real upstream lookups
  

Forwarders consistently outperform recursive resolvers by 2–5×.

---

7. Tips for More Accurate Benchmarking

• Run dnsperf from a separate machine to avoid local resource conflicts
  
• Disable DNSSEC for pure forwarder tests
  
• Use at least 100–10,000 domains to reduce cache effects
  
• Benchmark both UDP and TCP
  
• Try different durations: 10s, 30s, 60s
  
• Monitor CPU usage with htop

Frequently Asked Questions

Which are the top DNS resolvers?

1. Cloudflare DNS (1.1.1.1) – Privacy-focused, doesn’t log IP addresses, consistently one of the fastest globally. Supports DoH/DoT.

2. Google Public DNS (8.8.8.8 / 8.8.4.4) – Excellent reliability and uptime, massive infrastructure, extensive global coverage.

3. Quad9 (9.9.9.9) – Security-focused with malware/phishing blocking, non-profit, privacy-respecting, no personal data logging.

4. OpenDNS (208.67.222.222 / 208.67.220.220) – Content filtering options, phishing protection, popular for families and businesses.

5. AdGuard DNS (94.140.14.14) – Blocks ads and trackers at DNS level, family protection available, fast performance.

You can also explore DNS performance data at DNSPerf. We recommend choosing a DNS resolver that best matches the geographic location of your users for optimal performance.

What’s the difference between recursive and forwarding resolvers?

Recursive resolvers perform complete DNS resolution themselves, querying root servers, TLD servers, and authoritative nameservers. They offer full control but require more resources and have higher latency.

Forwarding resolvers simply forward queries to upstream resolvers (like 1.1.1.1 or 8.8.8.8) and cache responses. They’re faster, simpler to configure, and leverage optimized public infrastructure. Most internal networks use forwarding resolvers.

Can I use dnsperf to benchmark public resolvers?

Yes, but your results will include your network latency and routing to their infrastructure. This is useful for comparing public resolvers from your location, but not for measuring your local resolver’s capacity. For internal testing, always use a local IP address (192.168.x.x, 10.x.x.x).

Why do results vary between test runs?

Main factors: cache state (cold vs warm cache causes 10-100× difference), network conditions, server load, and time of day. For consistent results, run at least 3 iterations, discard outliers, and average the remaining results.

---

8. Conclusion

dnsperf is an essential, battle-tested tool for evaluating DNS resolver performance. Whether you’re tuning a small home resolver or validating a large-scale DNS service, dnsperf helps you measure exactly how fast and reliable your DNS infrastructure is.

With just a few commands, you can benchmark:

• Maximum throughput
  
• Latency under load
  
• Query loss
  
• Overall server health
  

Properly configured DNS resolvers on modern hardware can handle enormous query loads. With Unbound in forwarding mode on decent server hardware, achieving 50,000-100,000 QPS is routine, far exceeding the requirements of most deployments.