Benchmarks

​

Results

​

Authoritative

​

Cached forwarding

1. YADIFA 3.0.2 (the Debian 13 package) sends malformed NXDOMAIN answers (the SOA in the wrong section), one query in ten here, so its number is not quite comparable.
2. Not captured in this run; a 3-second trial run of the same harness showed 43.7 MiB.

• The top group is the load generator’s limit. Knot DNS, NSD, DNZ, PowerDNS, gdnsd, BIND 9, dnsdist, Knot Resolver and Unbound all land between 120k and 146k queries a second, within 21% of each other. That is what dnsperf sends from its 2 CPUs; their real capacity is higher, and this run doesn’t rank them among themselves.
• DNZ is in that group in both scenarios, while writing every query to its query log, with 1.1 to 1.2 ms of latency. v1.5.0 answered half as many at twice the latency (below). DNZ answers 2.5 times what CoreDNS does authoritative and 1.9 times CoreDNS and dnsmasq cached.
• Against the servers with a web UI, a query log and filtering, the ones people often pick instead of DNZ: Technitium answers 29% of what DNZ does, AdGuard Home 24%, Pi-hole 17% and Blocky 11%, with 6 to 13 times DNZ’s latency.
• Hickory DNS, the other DNS server written in Rust, answers 9% of DNZ’s authoritative and 15% of its cached queries (with its default info logging of every request).
• Memory: the C servers that only answer DNS mostly hold 3 to 30 MiB; NSD, PowerDNS Authoritative and YADIFA set aside 66 to 77 MiB. DNZ holds 40 to 62 MiB with its web API, query log and cache: less than AdGuard Home, Blocky and CoreDNS here, a third of Technitium.

​

Cache hits, before and after

​

From v1.5.0 to v1.6.0: UDP, a full cache and the query log

• UDP: one loop received every query and handed each to another thread. DNZ now binds the DNS port several times per CPU (SO_REUSEPORT, Linux) and answers local names and cache hits on the thread that received them.
• A full cache: every answer from upstream swept the whole cache for one to drop, 3 ms per insert with 100,000 entries, so names not yet cached ran at under 300 a second. Now 1.5 µs.
• Memory that kept climbing: the query log’s batches were written as one statement per batch size, and the database driver kept up to 100 of them prepared per connection. Under steady load the heap grew from 52 to 240 MB over 20 minutes; it now levels off within minutes.

​

Then: UDP in batches

• Less state per query: answering a query carried 22 KB of state, sized for its rarest paths, allocated and copied every time. Those paths keep their own now, and a query’s is 2 KB.
• The name once: a local answer wrote the query name out four times; now once, with a third fewer allocations.
• Batches: on Linux each socket reads the queries waiting on it with one recvmmsg (up to 32) and sends the answers with one sendmmsg, instead of a system call per query each way. A busy socket hands its thread over after 128 queries, so the others aren’t kept waiting.

​

Features compared

​

DNS

​

Running it

​

Operations

​

Counted up

​

Method

• Every server runs in its own container on one Docker network, with the same CPU and memory limits; only the server being measured is busy. The load generator is dnsperf in another container.
• The classic servers are the Debian 13 packages; CoreDNS, Technitium, AdGuard Home, Pi-hole and Blocky the official images; Hickory DNS a release build from crates.io; DNZ a release build.
• Authoritative: a zone of 10,000 A records, each queried in turn, with one query in ten for a name that does not exist. DNZ and Technitium get the zone through their import APIs like a user would; the others read the zone file.
• Cached forwarding: 10,000 names of another zone, which the resolvers forward to a Knot DNS container. One warm-up pass fills the caches, so the measured runs are all cache hits. Nobody validates DNSSEC here (DNZ’s default for forwarding).
• Defaults otherwise, with three exceptions, because all queries come from one address: rate limits are off (DNZ’s, Technitium’s, AdGuard Home’s, Pi-hole’s, and response rate limiting in NSD and YADIFA); caches have room for every name; servers that take a thread count get one per CPU. Each server keeps its default logging: DNZ writes every query to its query log, as Pi-hole, AdGuard Home and Blocky do; Technitium keeps statistics.

​

Memory

• The web server’s routes no longer compile into full regexes once per CPU.
• On Linux, DNZ uses one malloc arena per CPU and returns freed memory to the system every minute, so the minute after a large import or a burst of queries is the high point, not the new normal.
• The query log keeps every query for 7 days by default (DNZ_LOG_RETENTION_DAYS), so the database file grows until then. Tools that report a container’s memory including the kernel’s page cache show that file too; the kernel gives that memory back when something else needs it.
• Zones kept in memory no longer reserve room for four records under every name.

​

With blocklists and a threat feed

• Domains packed together. Every domain was a heap block of its own in a hash set, 58 to 69 bytes each. Now a list’s domains sit one after another in one buffer with a table of 4-byte positions, about 28 bytes each. The 2-million-host feed went from 132 MB to 54 MB on its own.
• Large inserts not kept prepared. Lists go into the database 5,000 rows at a time, and the database driver kept each such statement prepared: megabytes each, on each of eight connections, and one more whenever a refresh ended on a chunk of a new size.
• Cached answers without spare room. Each cached answer kept a 512-byte buffer; most need 100 to 200 bytes.

​

Threat detection on and off

​

Run it yourself

curl -fsSL https://github.com/terrific-ci/dnz/archive/refs/heads/main.tar.gz \
  | tar -xz --strip-components=1 dnz-main/bench
cd bench
./run.sh

BENCH_DURATION=60 BENCH_RUNS=5 BENCH_CPUS=4 ./run.sh