Which version of BIND do I want to download and install?

There are multiple versions of BIND available for download from ISC's website - how should you decide which one is right for your production environment?

The question has different answers, based on both the versions of BIND that are available, and what version of BIND you might be running already. Choose from the links on the right for some background on how BIND versions are managed and identified, followed by suggestions and recommendations for different situations.

We have two types of major BIND versions: Stable/Extended Support (ESV), and Development. Stable versions are even-numbered, Development versions are odd-numbered. (An ESV version is an older Stable version.) We also have a special edition of BIND, known as the -S or Subscription Edition, which is numbered the same way, but only released for Stable/ESV versions.

Major and minor BIND 9 version releases

BIND's current code base is BIND 9. Within BIND 9 there are major branches (versions). Examples of major branches are BIND 9.16 and BIND 9.18.  Each major branch has a series of minor releases, such as BIND 9.18.0, 9.18.1 etcetera.  The changes introduced by a new minor release depend on what type of BIND branch is being updated. Development Version minor releases introduce new and updated features and may not be backward compatible with their immediate predecessor.  Stable Version minor releases provide bug fixes only. All supported versions of BIND may occasionally receive unscheduled releases in response to a critical security bug, in which case the changes introduced between that version and its predecessor will be minimal and necessary only.

Development Versions

We release development versions off of the current working (master) branch. These are the odd-numbered major versions – BIND 9.13 was the first of these, followed by 9.15, 9.17, 9.19, and 9.21.

While BIND Engineers are developing new features, they release them regularly to the current Development Version of BIND. Development version minor releases introduce new and updated features and may not be backward compatible with their immediate predecessor.

Development versions of BIND are suitable for those interested in experimenting with and providing feedback to ISC upon their features. There will be no alpha/beta/release candidate versions of development versions, and it may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw.

Development versions will be frequently updated for 24 months.  At the end of the 24-month period, the stabilized development version will be re-labelled and re-released as the next stable version, and we will begin a new development branch.

Stable Versions

These will be the even-numbered major versions - for example, BIND 9.18 and BIND 9.20.

Historically, we have recommended waiting until the third maintenance release of a new branch before deploying in large scale production. Each major branch has a series of minor releases, such as BIND 9.16.0, 9.16.1, etc. Minor releases on a stable version will include bug fixes only, to maximize stability.

Extended Support Versions

ISC first introduced its ESV (Extended Support Version) versions in the summer of 2009 for users who have longer upgrade cycles.  At the time, we declared every second Stable version as ESV. When we decided to produce a new the Stable versions every 24 months, instead of every 12 months, we decided to make every Stable version an Extended Support Version.  Now we think of Extended Support as representing a maturity phase of a Stable version.

Every Stable version moves into Extended Support after a period of active development, and has a total lifetime of four years from initial release. Organizations with a long internal validation, integration, or deployment cycle should consider beginning their validation process with a Stable version and deploying when that branch enters the Extended Support phase.

Here are our current ESV versions and their EOL dates:

BIND 9.11 was supported until March, 2022.
BIND 9.16 is our old Stable/ESV version, supported until April, 2024.
BIND 9.18 is our current Stable/ESV version.

Unscheduled Releases

All supported versions of BIND may occasionally receive unscheduled releases in response to a critical security bug, in which case the changes introduced between that version and its predecessor will be minimal and necessary only.

Supported Preview Edition (also known as "Subscription Version," marked -S)

Releases marked with a -S are part of ISC’s Supported Preview edition. These releases provide a deployable, supported vehicle for our support customers to have early access to new features in development (as an alternative to running Development or ordinary annual Stable editions in their production or test environments). The -S edition is created for and available to support subscribers and may also be offered to community developers for testing and feedback. The -S edition includes select unreleased software (new features and other changes) that ISC judges to be stable enough for production use.  Features in the -S version may still be in development and may be changed or even removed by the time of the public release.

The -S edition releases are actively maintained and patched in case of security vulnerabilities, just as our regular public releases are. The -S edition is offered under the same license terms as the open source BIND, but redistribution is constrained by the support agreement between ISC and the support subscriber.

Supported Preview Editions will usually be based on the most recently released Extended Support Version.

Which version should I be running?

When managing BIND in a production environment there are several factors that influence the decision on which version of BIND to install:

• Stability and minimal code changes for a long period between updates
• Desired features and functionality
• Company policy on software installation and upgrade
• System administration process for deployment of new versions
• Consistency versus diversity

We recommend that you manage your production environment so that you're always running a currently supported version of BIND.  Older versions of BIND will be vulnerable to bugs and security defects that have been addressed in newer versions.

1. Stability, minimal change, new functionality unimportant, long pre-release & acceptance test cycle:

   If you are running BIND in an environment where stability is the overriding concern, and once you have selected a version to install, you want to minimize the changes to that software (while still being able to receive important bugfixes), then the Extended Support Versions of BIND would be recommended. These are
   always updated with security and significant bug fixes, but otherwise are minimal-change. We also provide advance notice of the next major version that, once stabilized, will become an ESV release.

   ESV releases are also ideal for situations where software
   upgrade/installation policy dictates that an extensive period of acceptance testing is necessary.  While you are running one ESV version in your production environment, you can be planning and testing for your next upgrade, secure in the knowledge that the version in which you're investing valuable test resources will also be supported for an extended period.  ISC Subscription Customers may also want to consider deploying the Supported Preview Edition as an alternative strategy.

   One other advantage of running with a BIND Extended Support Version is that the revisions are smaller, so setting
   up a process for scheduled testing for each new revision doesn't have to be as heavy as a major BIND upgrade. Then if there is a patch released for a security issue, you're most likely already running the latest version, so you can install the patched version as a low risk update as it's really close to what you've already deployed.

2. New functionality & features, ability to update/downgrade often and easily:

   For those environments where features and new functionality are more important and particularly when you want an early trial in a test framework, the current Development Version may be what you need. These versions are 'cutting edge' but as a result may be less stable - which means that you will be updating your version of BIND more frequently, and occasionally you may need to revert temporarily to an earlier version while awaiting a bug fix.

   With this version management strategy you'll also need to be planning to update soon after each new BIND minor version is released. New Development Versions are published monthly.

3. Stability and new functionality/features both important, happy to upgrade major version every 6-12 months:

   If you are interested in new functionality, but at the same time you're looking for stable production versions, the ESV lifecycle may be too long. We recommend in that case that you deploy the current Stable Version, upgrading to the next Stable branch when it becomes available. ISC Subscription customers may also want to consider deploying the Supported Preview Edition as an alternative strategy.

   With this version management strategy, in order to always be running a supported version of BIND with the latest feature set, you will need to plan to upgrade to the next Stable version of BIND as soon as it becomes available. But you can also preview/evaluate an upcoming Stable Release by installing the current Development Version in a test environment.

4. Stability via Diversity and Redundancy:

   Many deployments have built-in redundancy in their design.  That is, there will be no service interruption while several servers are unavailable due to either scheduled maintenance or unexpected problems.  A good strategy in this situation is to deploy servers running different versions of BIND.

   The advantage of this approach is that in many cases, new problems that are discovered are not applicable to all versions of BIND.  It also means that newer versions of BIND are being tested in the environment most likely to uncover any problems for you in production - that is, the real production environment!

Which version should I install in response to a Security Advisory?

If you've determined that the version of BIND that you're running is vulnerable, then you will (in most cases) be scheduling an emergency update of your production servers.  There will be little opportunity for extensive pre-release testing, so you should choose the new minor version that is closest to the version you're already running.

For example, if you were running BIND 9.16.1 and ISC released 9.16.8 and 9.17.10, you should install 9.16.8.

If you have not been updating BIND when a new minor version has been released, then it may mean that you have to jump several minor versions at the same time, but it is still the path of least change.

Do I need to upgrade each time ISC releases a new minor version?

You don't have to upgrade each time ISC releases a new minor version, although ISC recommends that you do. The changes for new versions are detailed both in the Release Notes and the CHANGES file distributed in the tarball and you should use those to make an informed decision on what is best for your situation.

ISC recommends that you do upgrade regularly if you can, because:

• The latest minor version/ESV revision should be more stable than its predecessor.
• You are proactively fixing bugs that you may not have encountered in your production environment yet, but which might cause interruptions to your server if you don't update.
• If ISC releases an advisory, then when you schedule an urgent update, the code change is only for the important or security issue (whereas if you have to jump up several minor revisions, the changes are going to be much more extensive).

Many BIND installations manage this by upgrading and monitoring one or more servers in advance of upgrading their entire fleet.

I'm running a really old version of BIND and need to upgrade - what do you recommend?

There are many reasons for finding yourself in need of a significant upgrade! "Really old" might mean BIND 8 or BIND 4, or it could just be that you're on a much older revision of BIND 9.

First you need to evaluate which version is going to be best for you in the long term. If you haven't already, read the earlier section: Which version should I be running? It's quite likely (but not certain) that the Extended Release Versions are going to be the ones most suitable for you.

Now that you have your 'target' version decided, here are some important tips:

• Read interim Release Notes - particularly those for the first (9.x.0) Stable versions.
• Look for changes in functionality, particularly in the setting of defaults that might need you to make changes to your configuration files.
• Some configurations or conditions that were acceptable in older versions of BIND may cause errors instead of warnings in newer versions (and in some cases there will be configuration switches to reverse the new default).
• The configuration file syntax changed between BIND 4 and BIND 8 - the named-bootconf script that can help convert the format is still distributed with BIND 9 today (in the /contrib/named-bootconf of the tarball).
• Newer versions of BIND 9 have more default empty zones to prevent leakage of non-resolvable queries to the Internet servers. See the Administrator Reference Manual for details, particularly if you are using any of the address ranges in your network infrastructure.
• If you are running authoritative servers - where are you setting the default TTL for your records? See:  Why does named log the warning message "no TTL specified - using SOA MINTTL instead"?
• The processing of wildcard records (using *) changed between BIND 8 and BIND 9
• The default Access Control Lists for handling client queries changed from BIND 9.4.1-P1 (to ensure that the default state of a server with minimal configuration is safe) - you may need to reconfigure your client access. See: What has changed in the behavior of "allow-recursion" and "allow-query-cache"

Plan and provision for testing BIND using your intended configuration files (and ideally, against a realistic query load) before upgrading.

Use named-checkconf -z to confirm that the newer version of BIND doesn't find any problems with your configuration and zone data files.

Ideally if you can, roll the new BIND version out to a single production server first - one that can be removed from your production environment if necessary.

ISC Support customers can contact ISC for upgrade advice applicable to their specific situation, as well as configuration audit and migration/version upgrade consulting.

More Information

More information on our product versions and support policy is available on our website and elsewhere in this KB:

• Software Support Policy and Version Numbering
• BIND Significant Features Matrix
• BIND blogs and updates on the web site
• BIND's Supported Platforms
• Current Support Status of BIND versions (with access to current downloads)