Step-by-step dnsperf guide

1. Prepare an isolated test environment

Place the dnsperf client and DNS server on separate machines or VMs where possible. Use a controlled network and monitor both systems. Avoid testing through uncontrolled routers, firewalls, VPNs, or Internet paths because they distort results.

2. Install dnsperf

# Debian/Ubuntu
sudo apt update && sudo apt install dnsperf

# Fedora/RHEL family (repository availability varies)
sudo dnf install dnsperf

# macOS with Homebrew
brew install dnsperf

3. Create a realistic query file

www.example.test A
www.example.test AAAA
example.test MX
example.test SOA
missing-001.example.test A

Save it as queries.txt. For meaningful performance tests, use a much larger, representative, authorized dataset.

4. Confirm basic connectivity

dig @192.0.2.53 example.test A

dnsperf -s 192.0.2.53 -d queries.txt -Q 10 -q 5 -l 10

5. Establish a baseline

Start with low QPS, low concurrency, and a short duration. Repeat the same test several times. Record server configuration, client hardware, software version, query file checksum, transport, and network conditions.

6. Increase one variable at a time

Increase QPS gradually while keeping the dataset, duration, outstanding requests, and server configuration unchanged. Then test concurrency, transport, DNSSEC, cache state, or response size independently.

7. Read the results correctly

• Queries sent/completed: request and response volume.
• Queries lost: requests without corresponding responses; investigate any unexpected loss.
• QPS: completed query rate, not simply the requested cap.
• Latency: average, minimum, maximum, and standard deviation.
• Connection statistics: especially relevant for TCP, DoT, and DoH.
• HTTP status codes: relevant to DoH tests.

8. Common mistakes

• Running dnsperf on the same overloaded host as the DNS service.
• Starting without a QPS cap.
• Using a tiny or unrealistic query file.
• Comparing warm-cache and cold-cache runs as if they were equivalent.
• Changing several variables between test runs.
• Ignoring packet loss, CPU saturation, file-descriptor limits, TLS setup, or network bottlenecks.

9. Safe test sequence

10 QPS → 50 QPS → 100 QPS → 250 QPS → 500 QPS

Stop increasing when latency, loss, CPU, memory, connections, or service health reaches your agreed threshold.