ISC's Software Support Policy and Version Numbering

ISC's Software Support Policy and Version Numbering
ISC's Software Support Policy and Version Numbering
Updated on
Feb 19, 2026
Published on Nov 1, 2014
10 minute(s) read
Ondrej Sury
Andrei Pavel
Prev
Next
The purpose of this article is to help users determine how long a given ISC release is likely to be supported. This information is useful when deciding when to schedule a migration, or in some cases, to help determine which version to migrate to when updating. This is a rough guide, not a guarantee, and release dates are approximate.
For the most current information on the status of any particular software version, please refer to the software status listed on the
downloads
page.
BIND 9 (updated as of September 9, 2024)
Major versions
We have four types of major BIND 9 versions: Development, Stable, Extended Support (ESV), and Supported Preview (also known as "Subscription," or -S).
Development versions
We release Development versions off of the current working (main) branch. These are the odd-numbered major versions, such as BIND 9.19, 9.21 etc.
We typically release minor Development releases monthly (e.g. 9.21.1, 9.21.2). Development version minor releases introduce new features and significant refactoring 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 are no alpha, beta or release candidates published. This process has been replaced with development versions. It may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw. Vulnerabilities in development versions are fixed as bugs, in regular maintenance versions, without separate patches, or CVE Advisories.
Development versions are maintained for 24 months. At the end of the 24-month period, the stabilized Development version is re-labeled and re-released as the next Stable version, and we will begin a new Development branch.
Stable versions
We stabilize all the even-numbered major versions for production use – for example, BIND 9.18 and BIND 9.20. Each major branch has a series of minor releases, such as BIND 9.18.0, 9.18.1, etc. Each even-numbered version is supported for a total of 4 years. It begins as a stable version, as it matures it is labelled as Extended Support, and finally, it receives vulnerability fixes only.
Stable branches of BIND get minor feature updates and bug fixes for approximately 12 months, but then are put into Extended Support mode and receive only critical fixes and eventually, only security patches. Within a Stable branch, users should be able to update from one minor version to another without worrying about a break in backward-compatibility.
This document has been recently updated to reflect a shift from bringing out new stable versions in Q1, to Q2. We observe a holiday freeze on announcing vulnerabilities over the year-end holiday period: this tends to mean Q1 frequently includes a security release, making Q2 a better target for a new stable version.
Extended Support versions (ESV)
Every Stable version moves into Extended Support after a year or so of active development, for 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.
Every Stable version will be declared ESV when the team feels confident that it is ready for conservative users. See the accompanying chart which shows when we plan to declare ESV status.
All dates are approximate. For example:
BIND 9.16 was declared End of Life in March, 2024, although we issued one final release in April, 2024.
BIND 9.18 was first released in January, 2022, and was declared ESV in January, 2023.
BIND 9.20 was first released in July, 2024 (release was delayed by security issues in Q1 and Q2).
BIND Open Source Release Plan
24 Q2
24 Q3
24 Q4
25 Q1
25 Q2
25 Q3
25 Q4
26 Q1
26 Q2
26 Q3
26 Q4
27 Q1
27 Q2
27 Q3
27 Q4
28 Q1
BIND 9.16 Stable
EOL
BIND 9.18 Stable
extended support (ESV)
ESV (vulnerabilities only)
EOL
BIND 9.20 Stable
stable
extended support (ESV)
ESV (vulnerabilities only)
BIND 9.21 Development
development
BIND 9.22 Stable
stable
extended support (ESV)
BIND 9.23 Development
development
Scroll to the right to see more of the table.
Supported Preview (also known as "Subscription," 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 receive early access to new features in development. The -S edition is created for and available to ISC paid support subscribers, and may also be offered to community developers for testing and feedback. The -S edition includes select unreleased software 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 based on an ESV branch, and are actively maintained and patched in case of security vulnerabilities, just as our regular public releases are. When we EOL a stable branch, we also EOL the associated -S edition version.
The -S support plan is different from regular releases:
When we put out a new maintenance release, we do a corresponding -S1 that normally includes all the bug fixes in the maintenance release, and is normally a superset of the code in the corresponding maintenance version.
We may add changes (new features) to the -S edition between maintenance releases that we do not add to a maintenance release of the public edition.
We support only one -S edition release on any given branch.
When we start producing an -S edition on a new branch, we continue to support the -S edition on the prior branch for at least another six months to support migration.
BIND Subscription Edition Release Plan (updated as of September 9, 2024)
24 Q2
24 Q3
24 Q4
25 Q1
25 Q2
25 Q3
25 Q4
26 Q1
26 Q2
26 Q3
26 Q4
27 Q1
27 Q2
27 Q3
27 Q4
28 Q1
BIND 9.16-S stable
EOL
BIND 9.18-S stable
ESV
ESV, vulnerabilities only
EOL
BIND 9.20-S stable
extended support (ESV)
ESV, vulnerabilities only
BIND 9.22-S stable
extended support
Scroll to the right to see more of the table.
Minimal updates
All supported versions of BIND 9 may occasionally receive unscheduled releases in response to a critical security bug; in that case, the changes introduced between that version and its predecessor are minimal and necessary only.
Operating System support
We have a published list of supported operating systems. These are the operating systems we can test on, or that we know to work. BIND may compile and run on other operating systems or versions but we don't guarantee it and we cannot commit to fixing issues with those operating systems or building packages for them. Please refer to the
BIND ARM
or
this KB article
for more information.
Some of our ISC packages for BIND are built and hosted on external sites. We cannot begin building these until the open source releases are published, and sometimes building and publication of these packages is delayed by factors outside our control (e.g. if the external repository is busy or unavailable.)
End of Life
Historical EOL dates for BIND versions are documented
here
Deprecating features
We have established a
process for removing named.conf options
. This is a gradual and phased process intended to provide ample notice of a coming change that might break an established configuration.
Kea (updated as of June 17, 2025)
We have two types of major Kea versions:
Development
and
Stable
. At any given time, we should have three options available: two Stable releases and one Development release.
Development versions
We release Development versions off of the current working (master) branch. These are the odd-numbered minor versions (where the second digit of the release number is odd), starting from Kea 2.5.0, 2.5.1, 2.5.2 and so on, until that branch is replaced with the next odd-numbered minor version, Kea 2.7.0.
We typically issue Development branch releases monthly. These minor updates will introduce new and updated features and may not be backward-compatible with their immediate predecessor. Development versions of Kea are suitable for those interested in experimenting with and providing feedback to ISC, but are not recommended for production use. 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. We may not issue patch releases for Development versions with vulnerabilities, at our discretion.
Development versions are maintained until the next Stable version is created, at which time we begin a new Development branch (with the next odd number). We estimate Development versions will mature into Stable versions in approximately a year, but this is a prediction, not a promise.
Stable versions
All the even-numbered minor versions (where the second digit of the version number is even) are for production use – for example, Kea 2.6 and Kea 3.0 are Stable versions. Each of these branches may have a series of maintenance releases, such as Kea 2.6.3, etc. Maintenance releases on a Stable version include bug fixes only, to maximize stability. There is no fixed schedule for issuing maintenance releases and we will release one only if there are significant issues to repair.
Stable versions of Kea are fully supported for at least three months after the next Stable version is released. This means you should have ample time to migrate to a new Stable version before the older one is EOL. Kea 3.0 is our first long-term support version, with a 3-year supported lifespan. Interim stable versions will be supported for one year. We aim to update the Kea packages the same day we post the tarballs.
Kea 3.0 followed directly after Kea 2.6, skipping the 2.8 version number. We wanted to clearly mark 3.0 as a version with several 'breaking' changes that will require a more careful upgrade.
Kea Release Plans
24 Q3
24 Q4
25 Q1
25 Q2
25 Q3
25 Q4
26 Q1
26 Q2
26 Q3
26 Q4
27 Q1
27 Q2
27 Q3
27 Q4
28 Q1
28 Q2
Kea 2.4 - Stable
stable
EOL
Kea 2.6 - Stable
stable
EOL
Kea 2.7 - Development
development
Kea 3.0 - Stable LTS
stable
EOL
Kea 3.1 - Development
development
Kea 3.2 - Stable
stable
EOL
Kea 3.3 - Development
development
Scroll to the right to see more of the table.
Operating System support
We have a published list of supported operating systems. These are the operating systems we can test on, or that we know to work. Kea may compile and run on other operating systems or versions but we don't guarantee it and we cannot commit to fixing issues with those operating systems or building packages for them. See the
platforms.md
statement in the Kea repository.
Stork (updated February 17, 2026)
All Stork releases prior to Stork 2.0 are experimental. Stork 2.0 is the first stable branch. Stork is evolving rapidly, so we plan to create a new stable version every 6 months, and will provide approximately a calendar quarter of overlap to support migration as we end support for each old stable version.
24 Q3
24 Q4
25 Q1
25 Q2
25 Q3
25 Q4
26 Q1
26 Q2
26 Q3
26 Q4
Stork 1.9.0 - Development
dev
Stork 2.0 - Stable
stable
Stork 2.1 - Development
development
Stork 2.2 - Stable
stable
Stork 2.3 - Development
development
Stork 2.4 - Stable
stable
Stork 2.5 - Development
development
Stork 2.6 - Stable
stable
Operating System support
We have a published list of supported operating systems. These are the operating systems we can test on, or that we know to work. Stork may compile and run on other operating systems or versions but we don't guarantee it and we cannot commit to fixing issues with those operating systems or building packages for them. See the
Compatible Systems
section in the ARM.
Other general policy guidelines
Standard support terms do not apply to Development releases or the BIND Supported Preview edition. Development releases are typically shorter-lived releases and are not recommended for production deployment. When we issue a release, we will create packages for
currently supported operating system versions only
. We cannot support obsolete operating system versions.
ISC DHCP - EOL
ISC DHCP has reached the end of public maintenance. Historical EOL dates for ISC DHCP are
here
. We previously maintained two branches of ISC DHCP:
DHCP 4.1-ESV was originally scheduled to go to EOL in December 2015, but we extended this until 4.1-ESV-R16-P2 to maintain a smaller-footprint edition.
DHCP 4.4 was the most recent ESV version.
The client and relay components were EOL with version 4.4.3. The server components were EOL with version 4.4.3-P1.
All other versions of ISC DHCP, including 4.2.x and 4.3.x, are EOL.
ISC ceased support for the ISC DHCP Client and Relay by the end of Q2, 2022. ISC ceased public support for the Server at the end of 2022.
ISC is still supporting the DHCP server
for existing technical support customers
. There is no end date established for this EOL-support service.
Related articles
Policy for removing named.conf options
BIND 9
BIND 9 Significant Features Matrix
BIND 9
BIND 9 End-of-Life Dates
BIND 9 > Release Notes
ISC DHCP End of Life Dates
ISC DHCP (now EOL) > Release Notes
Which version of BIND do I want to download and install?
BIND 9 > Getting Started
ISC Software Defect and Vulnerability Disclosure Policy
About ISC
Tags
aa-00896
BIND
bind 9
BIND Versions
Development versions
eol, end of life
EOS
isc
kea dhcp
Release Lifecycle
Stable
Support Policy