BIND 9.11.2, 9.10.6 & 9.9.11 Maintenance Versions Posted

New maintenance versions of each of our supported branches are available from our downloads page. We have also updated our 9.9 and 9.10-based Stable Preview releases; both are available to eligible support subscribers through your support queue.

We issue BIND maintenance versions approximately every 6 months.

Preview of BIND 9.12

Our next planned BIND release will be a new feature branch, BIND 9.12, currently planned for December 2017. The 9.12 release will include significant refactoring of key functions in BIND, plus implementations of several improvements to increase efficiency and resilience, including NSEC Aggressive Use and serving stale data when the authority is unresponsive. We are excited to be including a number of changes which improve authoritative performance dramatically for the root and TLD zones, and significantly for other deployment scenarios.

We are ceasing support for lwresd, and recommending that any remaining users consider adopting getdns instead.

Consider updating your signing algorithm

Due to recent developments in cryptography, we will be removing the existing default signing algorithm from dnssec-keygen in BIND 9.12; users will now be required to specify signing algorithms explicitly when generating a key with this utility. We are not deprecating any supported algorithms at this time.

We hope this encourages a transition to more secure algorithms, but it will add another configuration choice for new users, and it may break scripts that currently rely on the existing default behavior. The dnssec-keymgr utility can help implement an algorithm change; update its default signing algorithm by changing the policy configuration file.

Release notes are posted next to the downloads. Below are some highlights.

Major changes in 9.11.2
New DNSSEC Root Key

ICANN is in the process of introducing a new Key Signing Key (KSK) for the global root zone. BIND has multiple methods for managing DNSSEC trust anchors, with somewhat different behaviors. If the root key is configured using the managed-keys statement, or if the pre-configured root key is enabled by using dnssec-validation auto, then BIND can keep keys up to date automatically. Servers configured in this way should have begun the process of rolling to the new key when it was published in the root zone in July 2017. However, keys configured using the trusted-keys statement are not automatically maintained. If your server is performing DNSSEC validation and is configured using trusted-keys, you are advised to change your configuration before the root zone begins signing with the new KSK. This is currently scheduled for October 11, 2017.

This release includes an updated version of the bind.keys file containing the new root key. This file can also be downloaded from

Windows XP No Longer Supported

As of BIND 9.11.2, Windows XP is no longer a supported platform for BIND, and Windows XP binaries are no longer available for download from ISC.

Security Fixes (previously issued in patch releases)
  • An error in TSIG handling could permit unauthorized zone transfers or zone updates. These flaws are disclosed in CVE-2017-3142 and CVE-2017-3143. [RT #45383]
  • The BIND installer on Windows used an unquoted service path, which can enable privilege escalation. This flaw is disclosed in CVE-2017-3141. [RT #45229]
  • With certain RPZ configurations, a response with TTL 0 could cause named to go into an infinite query loop. This flaw is disclosed in CVE-2017-3140. [RT #45181]
Bug Fixes
  • Fixed a bug that was introduced in an earlier development release which caused multi-packet AXFR and IXFR messages to fail validation if not all packets contained TSIG records; this caused interoperability problems with some other DNS implementations. [RT #45509]
  • Reloading or reconfiguring named could fail on some platforms when LMDB was in use. [RT #45203]
  • Due to some incorrectly deleted code, when BIND was built with LMDB, zones that were deleted via rndc delzone were removed from the running server but were not removed from the new zone database, so that deletion did not persist after a server restart. This has been corrected. [RT #45185]

Thank You

Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at

Recent Posts

What's New from ISC

Someone on the Internet is committing fraud

Update posted June 27th, 2024 This was not the fraud we thought it was We have learned that emails we originally identified as abuse were sent by an external contractor engaged by ISC to conduct a focussed and short-term lead generation campaign.

Read post