Which version of BIND do I want to download and install? (Superseded)
- Updated on 03 Jan 2018
- 13 minutes to read
As of BIND 9.13, the content of this KB article is superseded by a revised BIND release and support policy
The revised and updated version can be found at 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. First, some background on how BIND versions are managed and identified. This is then followed by suggestions and recommendations for different situations:
- Major and minor BIND9 version releases
- Extended Support Versions
- Patched Versions
- Development Versions
- Which version should I aim to be running?
- Which version should I install in response to a Security Advisory?
- Do I need to upgrade each time ISC releases a new minor version or ESV revision?
- I'm running a really old version of BIND and need to upgrade - what do you recommend?
- More information
Examples of major releases are BIND 9.9 and BIND 9.10. Within each major release will be several minor releases, such as BIND 9.9.6, 9.10.0 et cetera.
Major releases are based upon significant new features being introduced to the code. The new features are added early on, and therefore BIND major versions tend to stabilize as the minor version numbers (9.x.0 -> 9.x.1 ...) increment.
BIND software releases are supported until two major releases have come out after them. With this strategy, support for 9.8.x was phased out 6 months after 9.10.0 was introduced. ISC will support no more than four major releases of BIND at any one time.
Examples of extended support versions are BIND 9.6-ESV-R11-W1 (now EOL) and BIND 9.9.6 (Extended Support Version).
ISC first introduced its ESV (Extended Support Version) versions in the summer of 2009 for users who have longer upgrade cycles. The ESVs are supported for longer period - and we aim to give to customers running ESV versions, a planned upgrade path by announcing the next ESV in good time. (Major versions of BIND released in between ESVs have a shorter support life.)
After it has been decided and announced that a major version of BIND will become an ESV, then once its new features have stabilized (it may take several minor releases to reach this point), the next release on that major code branch will be designated an ESV. ESV versions are always updated with security and significant bug fixes, but will not attract any new feature changes that might impact their stability.
In earlier versions of BIND, once the major release had stabilized, the ESV release removed the minor number from the version string, replacing it with "-ESV". Thus the first Extended Support Version for BIND 9.6 (superseding BIND 9.6.3) was named 9.6-ESV. With this naming convention, when we updated the ESV, we appended a revision number - for example 9.6-ESV-R9.
From BIND 9.9, we changed the naming convention for Extended Support Versions. The normal minor version numbers continue to increment as before, but the ESV designation will appear in parentheses afterwards. BIND 9.9.3 (Extended Support Version) was the first ESV version of BIND 9.9.
Occasionally there is the need to interrupt the planned release schedule to provide a fix for a serious problem that has unexpectedly arisen. In most cases there will be a Security Advisory issued at the same time. The significant feature of patched versions is that they contain only the necessary changes to address the problem that has been identified. They are a direct replacement for the unpatched version of BIND that they supersede. Examples of patched versions have been 9.9.5-P1 and 9.6-ESV-R11-W1. We append the patch level (e.g. -P1, or W1) to the original version string. ( The '-Wx' patch level denotes that the change only impacts the Windows version of BIND, but we replace the entire download/release anyway ).
ISC will patch (it may be clearer to think of this as 'replace') the last minor or ESV version of all currently-supported major releases when there is a significant problem that needs to be addressed outside of the normal release schedule.
Product releases have a lifecycle that includes alpha, beta and release candidate versions before they become general release. We make these development versions available for download, but we would not recommend their use in most production environments. Examples of development versions are 9.9.2b1 and 9.9.1rc1.
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.
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 mostly 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, the most recent production version of BIND is for you. 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, occasionally may need to revert temporarily to an earlier version while awaiting a bug fix.
For new features and functionality, but a slightly more conservative approach, we'd recommend waiting for the 9.x.1 version of any new major release. New features, whilst being thoroughly tested ahead of release, often need adjusting slightly following their real life 'road test'.
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. The traditional approach for sites that can afford to upgrade their BIND software relatively often, is to deploy the last but one major release of BIND (e.g. while BIND 9.10 is the latest, they are running 9.9.x).
Since BIND software releases are supported until two major releases have come out after them - and then there is a 6 month period in which to test and upgrade to the new 'last but one' version.
Occasionally new functionality available in the latest version means that an earlier than usual upgrade takes place - but we'd still recommend waiting for the 9.x.1 or 9.x.2 version.
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. For example, half each on 9.10 and 9.9 or 9.9 and 9.6-ESV. Since ISC supports the latest two major versions, as well as supporting the these three for 6 months after a new major version release, this provides administrators with a six month window in which to evaluate the new version and roll the half of their servers running the oldest major release to the newest.
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!
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 patch version that is closest to the version you're already running.
For example, if you were running BIND 9.9.6 and ISC released patches for 9.9 and 9.10, then you should install the 9.6 patch version.
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.
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 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 a patched version, 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.
There are many reasons for finding yourself in need of a significant upgrade! 'Really Old' might mean from BIND8 or BIND4, or it could just be that you're on a much older revision of BIND9.
First you need to evaluate which version is going to be best for you in the long term. If you haven't already, read this earlier section: Which version should I aim to 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 minor 9.x.0 and 9.x.1 versions.
- Look for changes in functionality, particular 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 BIND4 and BIND8 - the named-bootconf script that can help convert the format is still distributed with BIND9 today (in the /contrib/named-bootconf of the tarball).
- Newer versions of BIND9 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 BIND8 and BIND9
- 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. ISC also offers Configuration Audit and Migration/Version Upgrade Consulting Packages.
More information on our product versions and support policy is available on our website:
- Version numbering
- Software Support Policy
- Current Support Status of BIND versions (with access to current downloads)
© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.