Performance Improvements in BIND 9.20 in Authoritative Configurations - December 2025

BIND 9.20 is well established and stable. This is a good time to look at the performance of BIND 9.20 vs 9.18 as many users have not yet adopted 9.20. The bottom line is, BIND 9 authoritative server performance is remarkably stable, and authoritative users updating from 9.18 to 9.20 should anticipate a small performance improvement. Some users, with a large number of zones, may see a significant increase in memory usage, however, as explained below. There are a number of other changes to be aware of when moving from BIND 9.18 to 9.20, which are explained in this Knowledgebase article.

As part of the development cycle of BIND 9, we carry out a set of performance tests. Our performance laboratory system for DNS authoritative testing (somewhat unimaginatively called “perflab”) continually cycles through all configurations registered with it, building BIND 9 and running performance tests. (Details of the system have been presented elsewhere, so they will not be described here.) In this way, as the development branches are updated with changes, the effect of those changes on performance is quickly visible. We use a completely different methodology for testing DNS resolver operations, because that is impacted by factors on the live Internet, and tests with canned queries are a poor predictor of real-world performance. Resolver performance results will be presented in a separate blog post.

We have six test profiles:

• One million zones: These tests simulate the environment of a web hosting provider, whose server might be serving zones for a number of customers. Each of the zones in the test is very small, comprising just an SOA, NS, A, and AAAA record. Note that in this scenario, there is a significant 28% increase in memory use in 9.20. We have prioritized performance and stability, vs memory usage.
• One million delegations: This configuration simulates a large top- (or second-level) domain, where the zone comprises almost exclusively delegations to the zones of subdomain owners.
• The se-TLD zone. This is a download of the actual .se zone, with all the DNSSEC records stripped out. (It is a copy of the TLD tab from this benchmark from CZ.NIC: https://www.knot-dns.cz/benchmark/).
• The se-TLD-nsec zone, which is the actual .se zone, signed with NSEC (not NSEC3), queried with the names of the zones with a random suffix appended, a bit like a pseudorandom subdomain attack.
• One million resource records: This is the opposite extreme to the one million delegations test. In that test, BIND returns referrals in response to queries; in this test BIND returns resource records from within the zone.
• Root zone: As some of the twelve root server operators run BIND on at least some of their servers, and given the crucial importance of the root zone to the global DNS infrastructure, we test the performance of BIND when serving a copy of the root zone.

For each scenario, the query set is one that will result in about 5% NXDOMAIN responses (with the exception of the root zone test, where we would expect a much higher rate of NXDOMAINs).

To obtain a figure for the query rate that BIND can handle, perflab starts up the server under test. It then fires queries at the server for 30 seconds and calculates a query rate. It runs the 30-second measurement 10 times for a single test. The first measurement is discarded from calculations, to allow the server to settle down, i.e., for all data structures to be created and reach their final size. In order to ensure the stability of the results, we repeat this procedure around 50 times. In the table below we report the median across the 50 tests.

We also measure memory usage. For those scenarios where it is relevant, we measured memory usage when the server first starts up, when the glue cache is empty. (This is obviously not representative of a real operational scenario, but a baseline.) The second measurement is actually the maximum memory usage, after the glue cache is presumably fully populated.

Test Results

• BIND 9.20 performed 4 - 7% better than 9.18 in these tests for most profiles. The gain was greatest in the 1M delegations profile, and least for the root zone and 1M zones profile.
• Memory usage was relatively flat, with two notable exceptions: BIND 9.20 used 28% more memory in the 1M zones test and 35% less memory in the se-TLD zone test.

The increased memory usage with many small zones is due to changes we made to improve scalability.

Both 9.18 and 9.20 use a per-zone pool of locks to ensure that the server can keep serving a zone while a zone transfer is in progress. For 9.20, we increased the size of the lock pool and introduced a new, higher performance kind of lock. This leads to increased performance across the board, but incurs a fixed memory overhead per-zone. On deployments with a large number of small zones, this overhead adds up. In 9.21, we switched to a global pool of locks, instead of a per-zone one. This will resolve the memory issues for deployments with a large number of zones with the release of our next stable version, BIND 9.22.

The decrease in memory usage in the se-TLD test is due to optimizations done to the glue cache in 9.20.

Authoritative performance (queries per second) of BIND 9.18.42 vs BIND 9.20.16

Here is the data in table form.

Performance (QPS)

Absolute Performance in Queries Per Second

Percentage Increase in QPS of 9.20 vs 9.18

Memory usage (MB)

Absolute Memory Usage

Percentage Increase in Memory Used in 9.20 vs 9.18

We hope that this information helps alleviate concerns about a performance regression from the list of considerations when planning an update to BIND 9.20.