It’s 2 AM. My phone is buzzing with alerts. DNS latency for our primary cluster just spiked from a steady 10ms to a staggering 500ms. Users are reporting that ‘the internet is down,’ even though our backbone links are nearly empty.
The culprit? Our DNS recursors are choking under a 10x surge in traffic. In these moments, you don’t need a tool that just says ‘it’s slow.’ You need a tool that identifies the exact breaking point. Over the years, I’ve relied on dnsperf and resperf to solve these puzzles.
Quick Start: Running Your First Test
When you’re in the middle of an incident, you don’t have time to read a 50-page manual. You need to know right now if your server can handle the current Queries Per Second (QPS). Originally developed by Nominum and now maintained by DNS-OARC, dnsperf and resperf are the industry standards for DNS benchmarking.
1. Installation
Getting these tools on modern Linux distributions is a one-minute job. For Ubuntu or Debian users, run:
sudo apt update
sudo apt install dnsperfIf you are on RHEL or CentOS, enable the EPEL repository first:
sudo yum install epel-release
sudo yum install dnsperf2. Building Your Query File
Neither tool generates random queries. They require a ‘datafile’—a simple text file listing the domains and record types you want to test. Create a file named queries.txt:
google.com A
facebook.com A
itfromzero.com AAAA
cloudflare.com MX
linux.org AFor a meaningful test, don’t just use five lines. I typically extract 50,000 to 100,000 unique queries from my actual querylog to mimic real user behavior and bypass simple cache hits.
3. The First Benchmark
Let’s test a local DNS server at a steady 100 QPS for 30 seconds:
dnsperf -s 127.0.0.1 -p 53 -d queries.txt -l 30 -Q 100The report will show how many queries were sent, how many were lost, and the average latency. If your ‘Lost queries’ count is zero and latency stays under 20ms, your server is breathing easily. If latency climbs while QPS stays low, you have a configuration bottleneck.
Choosing Your Tool: dnsperf vs. resperf
While they come in the same package, they serve different roles. Picking the wrong one will give you misleading data.
dnsperf: The Throughput Specialist
I use dnsperf primarily for Authoritative DNS servers. It sends queries at a fixed rate. It’s perfect for answering: “Can my server handle 50,000 QPS of static records?” It maintains a consistent load to measure stability over time.
resperf: The Capacity Finder
resperf (Resolution Performance) is built for Caching and Recursive DNS servers. Unlike its sibling, resperf starts with a low query rate and ramps it up until the server fails. This reveals your ‘ceiling.’
When I migrate to a new hardware load balancer, I run resperf to find where the response curve flattens. During one recent migration, resperf showed our new VMs could handle 12,000 QPS, but latency tripled at 13,000 QPS. This allowed us to set precise rate limits before we ever went live.
Advanced Stress Testing
Production environments are messy. To get data you can actually trust, you need to push the tools harder.
Finding Max Capacity
To find the absolute maximum QPS your server can handle, use the ramp-up feature:
resperf -s 192.168.1.10 -d queries.txt -m 10000The -m flag sets the maximum QPS target. resperf outputs a data block every second. Look for the point where “Actual QPS” stops growing even as “Target QPS” rises. That is your limit.
Utilizing Multiple Threads
On high-performance servers, like a 32-core BIND or Unbound setup, the benchmarking tool itself can become the bottleneck. Use the -T flag to spread the load across multiple CPU cores on your testing machine:
dnsperf -s 10.0.0.5 -d queries.txt -T 4 -l 60 -Q 20000Simulating Distributed Clients
Firewalls often use rate-limiting based on source IPs. If you run a massive test from a single machine, a firewall might drop your packets, skewing the results. You can bypass this by running the tool from multiple containers or using the -x flag to simulate different source ports.
How to Fix Ugly Benchmark Results
If your benchmarks show high latency or dropped packets, don’t panic. Here is my checklist for tuning underperforming DNS nodes.
1. Open File Limits
DNS servers handle thousands of concurrent connections. If the OS limit is too low, queries will simply vanish. Check your current limit with ulimit -n. For production nodes, I always set this to at least 65,535 in /etc/security/limits.conf.
2. Memory and Cache Sizing
If resperf shows high latency for recursive queries but fast responses for repeats, your cache is too small. For BIND, check max-cache-size. For Unbound, look at rrset-cache-size. Increasing these values ensures the server answers from RAM instead of waiting on upstream root servers.
3. Multithreading and CPU Pinning
Watch your CPU usage during a dnsperf run. If one core is pinned at 100% while others are idle, your software isn’t multithreading correctly. In Unbound, you must explicitly set num-threads to match your core count. In BIND, ensure you use the -n flag for the number of worker threads.
4. Tuning the UDP Stack
Often, the bottleneck is the Linux kernel. I frequently increase the UDP receive buffers to prevent packet drops during traffic spikes:
# Set max UDP buffer to 16MB
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216Summary
Benchmarking isn’t about chasing the biggest numbers. It’s about predictability. By using dnsperf for baseline tests and resperf to find your breaking point, you can sleep better knowing exactly how much traffic your infrastructure can survive. I make these tests a mandatory gatekeeper in my CI/CD pipeline. Don’t wait for a 2 AM outage to discover your server caps out at 5,000 QPS—test it today.
