• Print
  • Share
  • Dark
    Light

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

  • Updated on 27 Sep 2018
  • 13 minutes to read
  • Contributors

This article reflects ISC's BIND Versioning, Support and Maintenance Policy from BIND 9.13 onwards

For our older Support Policy, please see: Which version of BIND do I want to download and install? (Superseded)

BIND 9.11 and 9.12 are included in the new Support Policy but are also part of the transition between old and new.

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.

Major and minor BIND 9 version releases

We have four types of major BIND versions: Stable, Development, Extended Support (ESV), and Subscription.

BIND's current code base is BIND 9. Within BIND 9 there are major branches (versions). Examples of major branches are BIND 9.12 and BIND 9.13. 

Each major branch has a series of minor releases, such as BIND 9.12.0, 9.12.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

Beginning in 2018, we will release development versions off of the current working (master) branch. These will be the odd-numbered major versions – starting from BIND 9.13.

While BIND Engineers are developing new features, they will 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 supported for 12 months.  At the end of the 12-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.14 and BIND 9.16.

Historically, we have recommended waiting until the third maintenance release of a new branch before deploying in large scale production. Beginning with BIND 9.14, we plan to publish a new Stable version annually. We will stabilize all the even-numbered major versions for production use – for example, BIND 9.14 and BIND 9.16.  Each major branch has a series of minor releases, such as BIND 9.14.0, 9.14.1, etc. Minor releases on a stable version will include bug fixes only, to maximize stability.

Stable branches of BIND are fully supported for 12 months, but will be EOL (End of Life) as soon as the next Stable version is released.

Extended Support Versions

ISC first introduced its ESV (Extended Support Version) versions in the summer of 2009 for users who have longer upgrade cycles. With the introduction of alternating Development and Stable Version releases, a new ESV will be released every 2 years (instead of the Stable Version for that year). 

Extended Support Versions will be supported for at least four years from initial release, thereby providing ample time for acceptance testing and upgrading during the overlap of the support period with their immediate ESV predecessor.  Organizations with a long internal validation, integration, or deployment cycle should consider using these versions.

Here are our current ESV versions and their EOL dates:

BIND 9.9 Extended Support Version will be supported until June, 2018
BIND 9.11 will be our next Extended Support Version, supported until December, 2020
BIND 9.16 will be our next ESV, followed by BIND 9.20; every second stable version after that will be ESV.

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. The software released in the -S versions will usually be available for experimental use via our public code repository and is all intended for eventual general public release. 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 (whilst still being able to receive important bugfixes), then the Extended Support Versions of BIND would be recommended. These have a longer support life and 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.  Whilst 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.

  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 at least annually to the next Stable or ESV 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 you will need to plan to upgrade to the next Stable version of BIND as soon as the current one reaches EOL. 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.11.1 and ISC released 9.11.4, 9.12.1 and 9.13.5, you should install 9.11.4.

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 or ESV revision?

You don't have to upgrade each time ISC releases a new minor version or ESV revision, 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.

There may be more changes in the CHANGES file than in the Release Notes

Not all changes appear in the release notes.  The ones that are omitted from release notes are usually internal changes that shouldn't impact production environments or which have been added to address theoretical and obscure corner-case problems that were uncovered through source code inspection or analysis tools.

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.

In some situations you may need to plan for two upgrades

If you're running an old but relatively recent version of BIND but want to move to using the Extended Support Versions, it's possible, due to the longevity of support for these versions, that you'll find yourself running a newer major version than the current ESV, whilst the next ESV is not yet available.  In that case, rather than go backwards on functionality/features, it is better to upgrade first to a stable major version as an interim step towards the next ESV.  This will mean planning for two upgrades instead of one. ISC support customers can contact ISC for advice applicable to their specific situation.

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 and ESV 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:

Problems with this site? Email us at marketing@isc.org