Kea 2.0 - Performance, Stability and Security
We are very proud to announce that we have just posted a new stable branch of Kea, Kea 2.Read post
It is summertime and even though you might rather be at the beach, this could be a good time to check in on what has been going on with BIND.
The biggest projects for the past year have been continuing the implementation of the new, refactored network interface using libuv, and the addition of support for the new DoT and DoH encrypted transports, including updating dig to send DoH queries. Back in January of this year, we announced a change in our release model, moving from 12-month branches to 24-month branches to give us more time on a new feature branch to complete large refactoring projects like the network manager, because we anticipate more similar projects in the future. We have made several adjustments to our Serve-Stale feature based on user feedback, and we have continued making improvements to the Key and Signing Policy (KASP) tool first published in 9.16. We have also updated our DNS Cookie support, tightening policy as deployment of DNS Cookies improves across the Internet. DNS Cookies are a useful and lightweight defense against the whole category of spoofing attacks on the DNS, such as the recently published SADDNS cache poisoning vulnerability.
Most of our efforts are spent on investigating bug reports, fixing bugs, modernizing and addressing technical debt. We are using a number of automated tools to help us find errors in BIND. Last fall we joined the Google OSS Fuzzing project, which promptly found 3 significant issues. We also use scanning services from lgtm, Coverity Scan, and Sonar Cloud. We test in house with LibFuzzer and AFL in addition to the cloud tools. We run thread and address sanitizers from LLVM/CLANG and GCC.
In the past year we have added dozens of new or updated system tests, closing over 60 test-related issues, and in the past 6 months we have developed a new resolver performance test bed, based on the DNS Shotgun tool from CZNIC, which is ‘loaded’ with actual captured, anonymized queries shared with us by users. We have also implemented pairwise testing of all build options (there are many of these in BIND).
Over the past couple of years we have made significant investments in building BIND packages for our users. With our monthly update cycle, it sometimes feels as if we are continuously re-building packages for Ubuntu, Fedora, Debian, CentOS and our Docker image. In response to questions about what platforms different BIND branches are supported on, we have created a matrix in our knowledgebase.
We are following the NIST efforts to develop new standards for secure software development. In addition, we are updating our answers to the questions for the Linux Foundation’s Core Infrastructure Initiative Best Practices Badge. We are trying to achieve compliance with one of the higher levels (we have Bronze, but they have recently added Silver and Gold levels.)
This spring we presented a series of classes developed and delivered by Carsten Strotmann. He covered logging, metrics, using dnsdist with BIND and using dynamic zones. Unfortunately it is too late to participate in the hands-on exercises, but the sessions were recorded. These might be a useful resource for new BIND administrators.
As always we welcome your comments on BIND development and our roadmap, and your active participation on the bind-users mailing list. We are currently looking to add another BIND developer to our team, so if you know any experienced developers who might be interested in working on a large and complex open source project, please let them know!
We will continue maintaining BIND 9.11 through the end of 2021, and will patch any significant security issues through Q1, 2022. Although we don’t usually change features in an open source Extended-Support (ESV) version, in the 9.11-S edition, we are backporting updates to the serve-stale feature as we are finding conflicts with other features, such as pre-fetch.
We are updating the platforms we test 9.11 on to the current versions of the supported operating systems. We have replaced Ubuntu 16.04 LTS with Ubuntu 18.04 LTS, added FreeBSD 13.0, OpenBSD 6.9 and Fedora 34. See the updated Supported Platforms https://kb.isc.org/docs/supported-platforms article in the knowledgebase.
We are continuing to add system tests for all supported branches, including 9.11. We are also checking performance of each release vs the prior one to ensure that we are alerted to any performance regressions (and there are none in these end of branch 9.11 releases).
Users still running 9.11, and we know there are many of them, should start planning their migration to 9.16 now. We recommend doing some non-production testing with your configuration if at all possible, and then deploying gradually, while monitoring for performance changes. 9.11 users upgrading will find the BIND ARM for 9.16 and later online at ReadTheDocs. DNSSEC users should consider adopting the new Key and Signing Policy tool that facilitates key management in 9.16.
With the June release of 9.16 we will have completed the transition to the new libuv-based network manager infrastructure. Our internal testing shows that recent changes to the network manager have fixed some resolver performance problems that have been plaguing 9.16 since we introduced the network manager. With these changes BIND 9.16 consistently performs as well or better than 9.11. Now we can finally end the refactoring work in this branch and declare 9.16 an Extended-Support version (ESV) in July, putting it into a more stable maintenance-only mode. At that time, we will advise more conservative users to start migrating from 9.11.
We will be posting a separate blog sharing some of our performance testing experience and results for 9.16.
In order to minimize ongoing churn in the 9.16 branch for ESV status, we have decided to retract our earlier pledge to backport DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) to 9.16. Backporting that to 9.16 at this point (we have almost no operator feedback on it yet) could mean months of further changes in 9.16. The next stable version, BIND 9.18, is now only six months away (expected release January 2022) and that is a better target for production deployment of DoH and DoT. If you are using either DoH or DoT in BIND, we would love to hear from you (use the bind-users list to share your experience).
We are currently projecting our new stable branch in January, early in Q1. We have a long list of pending customer-requested minor enhancements, many associated with troubleshooting or monitoring. We will try to do as many of these as possible before we create the new 9.18 branch. We have some work on-going on zone transfers and are planning additional RPZ logging. We have more work to do to make our DoH implementation more scalable. (This is a background activity based on the very low level of interest we have seen from the BIND user community.) We are also working on documentation improvements, including migrating some content from the ISC knowledgebase to the BIND ARM.
We are removing support for the Microsoft(TM) Windows platform. Our reasons are:
The resources that would be required for us to support new Windows and Visual Studio versions would be better spent elsewhere. The June release of the development branch (9.17.14) will be the last release with Windows support included. We have removed the Windows support code from our main branch. The next stable branch, BIND 9.18 will not come with Windows as supported platform. We will try to create a separate
dig.exe and post that as a separate download, so people can still use dig on Windows. If we are able to do this, it will not be an officially maintained product.
While this decision sparked controversy on the bind-users mailing list, when we raised this issue with our support customers several months ago, we received zero requests to extend support for BIND on Windows from them.
Currently, BIND 9 has two PKCS#11 interfaces:
ISC has sponsored significant improvements to the OpenSC engine_pkcs11, and the next OpenSC version (libp11 0.4.12) will include those improvements. The new version has better performance and is maintained by people with specific expertise in PKCS#11. Therefore, we intend to drop the native PKCS#11 interface from BIND 9.18 and recommend the OpenSC implementation instead.
What's New from ISC