Summer Update from ISC
Kea/DHCP news At the end of May, we released Kea 2.
Read post
Kea/DHCP news
At the end of May, we released Kea 2.6.0, our latest stable version of Kea. This major version introduced a number of features requested by network operators: a new ping check hook for subscribers, the hub-and-spoke High Availability feature, an option to “stash agent options” to preserve them for renewals, and a new performance monitoring hook. We also re-implemented the RADIUS client in our RADIUS hook library, and added support for more client options.
To help users upgrade to this new version, we published a support Knowledgebase article on Changes to Be Aware of When Migrating to Kea 2.6.0.
A lot of ISC DHCP users are just starting to look into migrating to Kea. We have collected some hopefully helpful tools and advice on a web page. Please feel free to post your questions about how to tailor your Kea configuration to meet your requirements on the kea-users mailing list, which has been quite active lately.
The Kea team produces a number of pre-compiled packages for Kea, and we think most of our users install from these. We have rearranged the Kea repositories on Cloudsmith so that all future development branches are now in the kea-dev (open source) or kea-dev-prv (subscriber-only) repositories. Read more in this blog post.
Stork update
For those of you who have not yet tried our Stork utility for Kea, we are currently working on hosting a live demo site for you to try out. Stork can aggregate information from a number of Kea servers at once in a single dashboard. This is not intended to replace your network fault monitoring system, but it can help identify dhcp issues faster. Stork also now leverages several Kea hooks to provide a graphical interface for managing your host reservations and subnet configuration. The graphical interface can help prevent errors and can broaden the team able to make configuration changes. For the easiest experience, we recommend installing Stork from the packages in our Cloudsmith repository and using the Stork Quickstart Guide. Stork is currently officially an experimental development project, but we are planning to release a stable version and begin offering professional support for Stork towards the end of this year.
Further Reading
- We have a new KB on Importing External Certificates to Stork
- Changes to be aware of when migrating to Kea 2.6.0
- We have updated the KB article on Logging for ISC DHCP users .
- We also have a new KB article on redefining standard options, and we have updated the list of options supported in ISC DHCP and Kea .
- If you couldn’t attend our December webinar on configuring Kea using Stork, check out the recording for a great demo.
A new BIND stable branch is coming - soon, we hope!
BIND 9.16 maintenance ended several months ago, after four years of active support (9.16.0 was released in March, 2020). If you have not already done so, please update to BIND 9.18, as soon as possible. We are confident that the performance and stability of the 9.18 branch of BIND is much improved over the older 9.11 and 9.16 branches.
We currently plan to release BIND 9.20 in mid-July. This release has been delayed, unfortunately, because we have been sidetracked by a spate of DNS and BIND vulnerabilities that were particularly difficult to mitigate. We always prioritize fixing security vulnerabilities, but obviously, their discovery is an unplanned distraction.
What’s the goal of all the refactoring?
BIND 9.20 continues our long-term commitment to refactoring and modernizing BIND. Fifteen or so years ago, DNS operators weren’t modifying their zones as frequently, or continuously maintaining large abuse filters. A lot of tasks that were occasional back then are constant today. In this most recent development cycle, the BIND developers have done a lot of work to reduce the pause in regular query processing that could sometimes occur when BIND was occupied with one of these periodic tasks. Many database functions have been refactored to use a new database (qp-trie), in place of the legacy red-black tree, as part of this effort. This has been a multi-year effort to enable BIND to perform better in today’s busier network environments, and take advantage of more powerful new hardware. We don’t yet have final numbers, but we expect BIND 9.20 to be significantly more efficient than 9.18 or 9.16 in typical deployments where task management has been an issue.
Since we mentioned zone transfers and user suspicions that they were blocking other query activity, have you noticed the new feature in the statistics channel, released in 9.18 and 9.19 earlier this year? This provides an HTML table showing incoming zone transfers by view, zone name, type, serial, transfer state, source, destination, transport, bytes, and messages received. This new statistic provides essential visibility into lengthy zone transfers.
All the encryption options
This is also our first stable branch with complete support for encrypted DNS. The US Government’s Encrypted DNS Implementation Guidance for federal agencies includes explicit recommendations for BIND deployment in section A3.1, using DNS over HTTPs or DNS over TLS. That document was written before the full support for encrypted DNS was available in a stable branch: with BIND 9.20, it is now fully supported. In the coming development cycle we plan to add support for the new QUIC transport, which is one of several modern protocols that are collapsing multiple OSI layers for greater efficiency.
One other new feature in 9.20 that may prove to be particularly useful is support for the Proxyv2 protocol. As explained in this blog post, this feature will pass client connection information to a backend system, which will allow it to perform some of the functions of the EDNS Client-Subnet Identifier feature, but without the cache impact. This may not help those of you who have peering agreements that require providing ECS information, but for those using the information in your own network, this may be more efficient.
Deleg record
ISC is contributing to specifications for a proposed new DNS record, the Deleg record, which would provide information about server capabilities. This could provide a more efficient way of finding, for example, a server that supports DNS over TLS. This draft has progressed to the point that the IETF has just chartered a new Deleg working group. For a quick update on IETF work on the DNS, read the slides for the recent talk Dave Lawrence (tale) gave at NANOG91, where he characterizes Deleg as the biggest change to the DNS since DNSSEC. Several ISC staff will be attending the upcoming IETF120 meeting in Vancouver, to work on this and other issues. As always, we would love to meet any users of our software, or anyone who wants to collaborate with us.
Further Reading
- Blog announcing the new Proxyv2 feature
- More Proxyv2 configuration examples
- dig versions and default EDNS UDP buffer size
- Changes to serve-stale option stale-answer-client-timeout in BIND 9.19 and newer (including 9.20)
- Stub zones don’t work when primaries are configured for “minimal-responses yes;”
- Rate Limits in BIND 9 Effective vs. DNSBomb Vulnerability
- Did you know we maintain a BIND 9 Docker image?
Recent presentations
- ISC staff have been traveling quite a bit, recently attending the CENTR Jamboree in Copenhagen, IETF in Brisbane, RIPE in Krakow, NANOG in Kansas City, and an ICANN meeting in Kigali. We normally post all our conference presentations on this web site. Here are a few recent ones:
- Encrypted DNS Policy call - Matthijs Mekking - slides, recording
- RIPE 88 - Open Source QA Process & Risk Mitigation - Petr Špaček - slides, recording
- RIPE 88 - The World* Turned Upside Down - Jeff Osborn - slides, recording
- NANOG91 - Open Source QA Process & Risk Mitigation - Victoria Risk - slides, recording
In addition, ISC’s General Counsel, Rob Carolina, appeared on the N2K/Cyberwire podcast earlier this summer to speak about, among other things, Quad9 and the DNS filtering case.
