BIND Release Model Update

Dear BIND Users,

At the end of 2017 we announced a new BIND release model. We introduced a published development branch, and established a time-driven cycle of monthly maintenance releases on both development and stable branches. In the process we shortened the interval between new stable branches to 12 months. (Previously we released new stable branches at longer intervals.) We reaffirmed our commitment to extended support versions with 4 years of maintenance, and announced that 9.16 would be our next ESV. We released the 9.12 stable and 9.13 development branches in 2018, followed by 9.14 and 9.15 in 2019, and 9.16 and 9.17 in 2020.

Changes for 2021

We plan to make a couple of significant changes to our established release model for 2021. We are not yet ready to create a new stable 9.18 branch at the moment. We are still making significant improvements to the current 9.16 branch, so a 9.18 branch would not provide any useful improvements from 9.16.

• We will not create a new stable branch until 2022. Thereafter we are planning to release a new stable branch every two years, rather than every 12 months.
• We will continue making significant changes in 9.16, which would be an exception to our normal procedure. Typically we refrain from making any feature changes in an Extended Support Version (ESV). While we haven’t formally declared that 9.16 is now ESV, we have made it clear that this was our plan for quite a while.
• Since we are introducing new stable versions more slowly, this means that now we can provide extended ESV support for every stable branch.
• Since we are not creating a new stable branch, and we want to preserve our even/stable, odd/development numbering scheme, we also don’t plan to create a new development version in 2021; instead, we will continue development on BIND 9.17.x.

The chart below shows the adjusted release plan going forward.

Why are we making this change?

During 2019 and 2020 we embarked on some refactoring that was more ambitious than we had attempted previously, replacing BIND’s proprietary network interface with the popular libuv library. This was a project that, we eventually came to realize, required more than a year to complete, and in fact, we are still not done with it. As a result, in BIND 9.16, we currently have both the legacy and the new network interfaces, and depending on the operation and BIND’s role in the DNS (client or server), we use one or the other. For the majority of servers, this hybrid approach runs smoothly, but unfortunately for others it has introduced new points of contention or bottlenecks. We would therefore like to complete the replacement of all legacy networking code before moving into the next development cycle. We need another quarter or so to finish this work.

In addition, we had pledged to backport support for DNS over TLS (DoT) and DNS over HTTPS (DoH) to 9.16. We don’t want a long-lived branch to lack these new transports, but this also means non-trivial changes to 9.16.

What does this mean for BIND users?

The 9.16 version, which should be fully stable and in minimal-changes mode by now, is not yet as quiescent as an ESV would usually be at this point. We are continuing to support 9.11 through Q1 2022. More conservative users may wish to stay on 9.11 until mid 2021, before adopting 9.16.

• We will honor our commitment to support 9.16 for four years from initial release. This does not change the support lifetime for 9.16, which is scheduled to end in Q1 2024.
• We will continue producing monthly maintenance and development releases, as we have been doing.
• Users will continue to have two open source branches suitable for deployment (9.11 and 9.16), the development branch for testing, plus two branches of the -S edition (again 9.11 and 9.16).
• We will continue to provide at least 9 months overlap between stable versions, allowing users ample time to migrate from one to the other.

Finally, the best part about this plan is, since every stable version will now eventually become an ESV, users who wish to stay on one branch for several years will now be able to.

What is the status of this change?

We notified ISC support customers of this planned change in December, to give them a chance to comment. Since we have received no expressions of concern, we have updated the official ISC Software Support Policy (https://kb.isc.org/docs/aa-00896).

We think this change is the best way to support our users. If you have concerns or questions please direct them to me (email below) or if you are on bind-users you may discuss this there.

Vicky Risk, Product Manager
vicky@isc.org

References

• ISC Software Support Policy (https://kb.isc.org/docs/aa-00896)
• 2017 blog on BIND Release Model (https://www.isc.org/blogs/bind-release-strategy-updated/)
• Policy for Removing named.conf Options (https://kb.isc.org/docs/policy-for-removing-namedconf-options)