BIND 9.14.0 Released

BIND 9.14.0 is our new stable branch for 2019.

As of BIND 9.13 and 9.14, BIND has adopted the “odd-unstable/even-stable” release numbering convention. BIND 9.14 contains new features added during the BIND 9.13 development process. Maintenance on the 9.14 branch will be limited to bug fixes and new feature development will proceed in the unstable 9.15 branch. [BIND-Announcement]

Major changes since BIND 9.12, the prior (2018) stable branch, include:

• Modernization and refactoring: the primary focus of our 2018 development efforts has been on modernizing BIND, refactoring complex code, and removing features and workarounds that are no longer needed.
• DNS Flag Day changes. Workarounds for servers that misbehave when queried with EDNS have been removed, because these broken servers and the workarounds for their noncompliance cause unnecessary delays, increase code complexity, and prevent deployment of new DNS features. In particular, resolution will no longer fall back to plain DNS when there is no response from an authoritative server.
• BIND can no longer be built without OpenSSL, which it now relies on for a non-blocking CSPRNG (Cryptographically Secure PseudoRandom Number Generator). Some older, insecure algorithm support has been deprecated.
• ISC can no longer validate or support some legacy systems, including old versions of UnixWare, BSD/OS, AIX, Tru64, SunOS, TruCluster, and IRIX. Some code supporting these has been removed.
• On UNIX-like systems, BIND now requires support for POSIX threads, the Advanced Sockets API for IPv6 (RFC 3542), and standard atomic operations provided by the C compiler.
• BIND’s task manager and socket code have been substantially modified. The manager uses per-cpu queues for tasks and the network stack runs multiple event loops in CPU-affinitive threads. This greatly improves performance on large systems, especially when using multi-queue NICs.
• A new plugin mechanism has been added to allow extension of query processing functionality through the use of external libraries. We plan to migrate some existing code to this new mechanism over time, and to leverage it for optional extensions, such as new DDoS mitigations.
• Zone types primary and secondary are now available as synonyms for master and slave, respectively, in named.conf.

As a result of these changes, you may need to update your configuration to remove options no longer supported.

There are two known configuration issues with this release: this release will not build with “–with-dlopen=no” and named will not load a configuration with “allow-update” and “allow-update-forwarding” at the global level. Both of these issues will be addressed in 9.14.1.

New Features

• QNAME Minimization was added and enabled by default in relaxed mode. This is a privacy-enhancing improvement that reduces the amount of query information unnecessarily shared with systems. Development of this feature was sponsored by the Open Technology Fund.
• Mirror zones enable named to serve a transferred copy of a zone’s contents without acting as an authority for the zone. This is designed for (and only for) serving a local copy of the DNS root zone. Development of this feature was sponsored by ICANN.

BIND 9.14 Performance Improvements

We tested using the current head of each major stable branch currently supported, which includes 9.11, our Extended Support version; 9.12, the stable branch for 2018; and 9.14, the new stable branch for 2019.

The following performance profile was generated using ISC’s PerfLab software (available on GitHub). The zone files and scripts used are also in the PerfLab repository on GitHub. The figures are not a guide for the absolute performance you should expect to see in any specific deployment, but they show significant relative performance improvements in the more recent versions, compared to the BIND 9.11 version.

Comparison of Performance, measured as Queries Per Second, across 3 stable branches of BIND

Performance has improved across the board, for each of the scenarios modeled. The huge jump in performance for the Root Zone is due primarily to the addition of a glue cache. The improvement in the other scenarios is mainly due to refactoring of the network socket code that enabled named to avoid context-switching (moving processing for a single query/response from one processor to another). Note that you will not observe this improvement if you test with dnsperf, because of some interaction between dnsperf and multi-threading support in BIND.

Related posts:

dnsgen – a DNS packet generator

BIND 9 Performance History