Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
With the January, 2023 maintenance releases, ISC is now encouraging all our users to consider updating to the 9.18 branch, if they are running an earlier branch. We are also announcing availability of the first 9.18-S Edition, for qualified ISC professional support subscribers. We feel that the 9.18 branch is as stable, or in some ways superior to, the existing 9.16 branch.
What does Extended Support Version (ESV) mean?
The ESV designation means a BIND 9 branch is stable enough for long-term adoption. BIND 9.18 has reached that milestone, and we encourage users running older versions to update to 9.18 now. In the past, ISC did not designate every version as ESV, but with our current release model, every even-numbered branch will be designated as ESV approximately midway through its active development cycle. We deem a branch ready for the ESV designation when there is a consensus between our development and technical support teams that the release is widely deployed and stable enough for us to encourage adoption by our more conservative users.
When we move a version into ESV status, we stop adding new features to it. We may still modify existing features, generally in response to bugs, but we try not to add new features. We might even defer bug fixes if we think there is a chance the fix might cause problems for some users.
How long will BIND 9.18 be supported?
One to migrate to BIND 9.18 now is that it has a longer support period ahead. BIND 9.16 will be supported through the end of 2023 while BIND 9.18 support will extend two years beyond that, through the end of 2025.
Through the end of 2024, the 9.18 branch will receive regular maintenance releases with fixes for serious issues and security vulnerabilities; no new features will be introduced. Minor feature changes may happen, especially in the course of mitigating a defect, as long as they don’t introduce backward compatibility conflicts. The last year of maintenance will be limited to critical and security issues only, and there will be no regular maintenance releases.
How does BIND 9.18 compare to BIND 9.16 and 9.11?
The BIND 9.18 branch is based on BIND 9.16, plus two years of additional development work. This development work included some very significant refactoring, which was already underway when we released BIND 9.16. Below are some of the major ways in which refactoring has updated BIND 9.18.
- BIND 9.18 completes the network refactoring work begun in 9.16
During 2020 and 2021 we refactored BIND’s networking interfaces to use the widely used Linux libuv library in place of the older BIND-specific networking code. BIND 9.16 uses the new libuv code to receive and process incoming DNS messages (from clients), but it still uses the older networking code for sending and processing outgoing DNS messages (to other servers). We completed the refactoring to use the new libuv code for both client and server communications in BIND 9.18.
The hybrid networking infrastructure caused some unexpected anomalies in 9.16. We have of course fixed those we identified, but there may be other subtle residual effects that are hard to pinpoint. Because the networking infrastructure is consistent in BIND 9.18, it is more stable. This was a substantial change in BIND, but one that should significantly improve long-term sustainability.
- Multiple listener model
In BIND 9.11 and earlier versions there was a single “listener” that distributed the incoming work between idle threads. In BIND 9.16 and later there are multiple listeners, directing incoming traffic to threads. There are benefits to each model.
To explain this, it might be helpful to envision the passport control line at an airport: generally, everyone is either all in a single long line, watching and listening to hear which passport examiner is free; or there is an airport staff person directing people to line up in front of different passport examiner booths. In the former case, there is some delay between the time a passport examiner finishes with one customer and when the next customer steps up to the window. It is a little inefficient, because new work is never queued up until an examiner is free. In the latter case, the examiner is working continuously, but there is always a risk that you might end up stuck in a line that isn’t moving because your examiner took a break, or is dealing with someone who doesn’t have a required visa.
The older, single-line model was less efficient than the current multiple-listener model, but it also consumed less memory. The multiple-listener model is more efficient, reducing latency. However, there is a risk with the multiple-listener model that some work could get stuck on a thread that is overloaded. The multiple-listener model relies on the Linux kernel to queue up work for threads. It is now possible to disable the multiple listener and revert back to the old behavior, in rare cases where you sometimes have very busy threads (e.g. doing high-volume transfers). We still think the new model is better, of course, but it is a change to be aware of.
- BIND 9.18 uses jemalloc for memory management
Another major change implemented in BIND 9.18 was the replacement of the legacy BIND memory allocator with the jemalloc memory allocator. The older memory allocator kept pools of memory for later reuse and would never free up the reserved memory. The jemalloc memory allocator is much better suited to the memory usage patterns that BIND 9 exhibits and is able to be both fast and memory-efficient.
- BIND 9.18 consumes less memory than 9.16 for the same application
As a consequence of the network refactoring and the switch to jemalloc, BIND 9.18 uses significantly less memory than BIND 9.16, and is therefore preferable for that reason. See this recent blog on BIND Memory Management for more details.
- The BIND Administrative Reference Manual (ARM) has been reorganized and some new material has been added, including diagrams; statements have been grouped into related categories with tags. This is part of an ongoing effort to provide more useful configuration guidance in the ARM, beyond command syntax.
What are the feature differences between 9.18 and 9.16?
In addition to refactoring, we also added a few new features in BIND 9.18, removed support for some older features, and updated our list of supported operating systems.
- Encrypted transport, with DoH and DoT
BIND 9.18 is the first stable branch with support for two new encrypted transports, DNS over HTTPS (DoH) and DNS over TLS (DoT). We have included the ability to limit connections over either transport, to avoid overwhelming a mixed-use system with more cpu-intensive encrypted connections. The popular dig tool can send both DoT and DoH queries, although we do not yet support forwarding over either DoT or DoH.
Neither of these new transports has become especially popular among BIND users as far as we can tell, but we do know some users are deploying zone transfers over TLS (XoT). Although we are proud of our implementations of these new transports, they should be considered experimental until there is more evidence of large, successful deployments. There are more details in the release notes and in the following blogs.
- Support for Catalog Zones schema v.2 (IETF standards-track)
Catalog zones are meta-zones that contain the list of zones to be served. ISC originally released an experimental, proprietary version of this feature, and since then we have worked with others in the IETF to propose a standardized implementation. We have updated our implementation in BIND 9.18 to support this new v.2 schema. This is another feature that has not yet been widely deployed at scale, so we appreciate feedback from those who are using it.
- Extended Errors
IETF RFC 8914 established 25 new error codes to provide more details with negative responses (typically with SERVFAIL responses). We have been implementing these incrementally in named. BIND 9.18 includes support for the first three we have implemented: #3 (Stale Answer), #18 (Prohibited) and #19 (Stale NXDOMAIN Answer). Additional extended errors are being added in the current development branch.
- Updates to the Key and Signing Policy (KASP) utility
This is the recommended, fully automated way to sign and maintain DNS zones. For most use cases users can simply use the built-in default policy, which applies up-to-date DNSSEC practices.
- Aggressive Use of DNSSEC-Validated Cache (
synth-from-dnssec, see RFC 8198) is now enabled by default again, after having been disabled in BIND 9.14.8
What features have been removed?
- Windows(tm) support has been ended
named and all utilities, including dig, are no longer available for Windows(tm).
- As announced in April 2021 on the bind-users mailing list and in our blog, support for BIND 9 on Windows has been deprecated. There is a list of the supported platforms in the BIND ARM and more detail in our Knowledgebase.
- There are a few other minor deprecations.
- Support for the map zone file format (
masterfile-format map;) has been removed. - Native PKCS#11 support has been removed and replaced with support for OpenSSL integration via the OpenSSL APIs.
- DSCP packet marking was non-operational and is being removed in a future version.
- Explicit definition of port numbers is also being deprecated from BIND; this has been available in all the operating systems we run on for more than a decade already.
We track features we plan to obsolete on the BIND Significant Features matrix.
There are, of course, many more changes that may affect certain users and environments. We always recommend reviewing the cumulative release notes, or the Changes log that refers to the releases between the one you are migrating from and the version you are moving to. Our support team has compiled a list of changes to BIND statements that may help you identify changes you should make to update your configuration.