BIND 9.16 Branch is approaching EOL
The BIND 9.16 branch is approaching EOL. This branch was first published on March 6th, 2020, four years ago.
Read post
Kea 2.4 is the newest stable branch of the Kea DHCP server, suitable for production deployment. If you have been waiting to deploy some of the new features previewed in our Kea 2.3 development branch, your wait is over. Kea 2.4 brings many new features developed during the Kea 2.3 development cycle to a production release. For full details of the new features, see the Kea 2.4.0 Release Notes.
Kea 2.0 is now EOL. If you are running Kea 2.0 or an older version, we recommend updating. Kea 2.2 will be supported until the release of Kea 2.6. See the ISC Software Support Policy for the Kea release schedule. We are still creating new stable branches annually, and supporting each until we have two newer stable branches. This helps us maintain an aggressive pace of new development. Although it may seem as if there is “nothing new” in DHCP, that is far from true: enterprise networks in particular are only getting more complex, and since DHCP is used as a control plane for devices, there is a steady stream of new feature requests. At some point, however, we may need to have a longer support lifetime, because users won’t want to update their DHCP servers even biennially. If any of our users think that time has come, we hope they raise the question on our Kea user mailing list.
There are some changes in this version that are not backward-compatible. Please consult our documentation on updating for changes that may impact your monitoring, package installation, and database schema.
New Lease Allocation Strategies
Since its inception in 2011, Kea has been using an iterative allocation strategy, which means it iterates through the address space and allocates available addresses sequentially. This is a simple, fast, and easy-to-understand allocation strategy that works for most use cases. We now have two additional allocation options; random and Free-Leases-Queue (FLQ).
The random allocator is somewhat slower than the iterative allocator but provides great resistance against scanning attacks, in particular when vast address space is available, such as in IPv6. This allocators should help reduce collisions when two or more Kea servers are assigning addresses from the same or overlapping pools, such as when using a shared database lease backend.
FLQ is a new allocation strategy. When the FLQ allocator is selected, Kea generates a list of all possible leases on startup and keeps it in memory; it uses this list to assign the first available lease from a pool. This allocator is suitable when DHCP servers are working with nearly depleted pools, and the time to find an available lease via other allocators becomes too long. This new allocator, however, slows down the server startup and reconfiguration, and it also uses more memory, so users may wish to experiment with it in their specific configuration. It can be used for address assignment in DHCPv4 and prefix delegation in DHCPv6.
The iterative allocator will remain the default, but the choice of an allocation strategy is now a configuration decision depending on the deployment requirements.
Bulk Leasequery
The subscriber-only Leasequery hook has been extended to support Bulk Leasequery (BLQ) for DHCPv4 and DHCPv6. BLQ allows rebooting routers and switches to reacquire their lost state by querying the DHCP server. BLQ differs from the typical DHCP protocol in two fundamental ways: first, it uses TCP, and therefore is connection-oriented; second, it does not follow the “one query, one response” paradigm. The “bulk” in BLQ means that devices can send a single query and receive many (possibly millions) of answers. We have done extensive internal testing and the feature appears to be stable, but we advise caution with its use. We are eager to get feedback on this topic, especially with regards to interoperability with other vendors. The DHCPv4 BLQ is currently available for all backends (memfile, MySQL, PostgreSQL). The DHCPv6 BLQ is currently available for memfile, with some very limited functionality for MySQL and PostgreSQL backends.
Package Updates
Our Cloudsmith repository for binary packages has become very popular, and we think the majority of our subscribers are now using that repository. Native Deb, RPM, and APK packages are available for Alpine 3.15, 3.16, 3.17; CentOS 7; Debian 10, 11, 12; Fedora 36, 37, 38; RHEL 8, 9; and Ubuntu 18.04, 20.04, 22.04. All packages are built for amd64 architecture. For details, see https://cloudsmith.io/~isc/repos/.
Kea’s official APK, Debian, and RPM packages have been restructured and made to follow a consistent packaging standard. Please see the new Installation From Cloudsmith Packages and Caveats When Upgrading Kea Packages sections in the Kea ARM for more details. Depending on how Kea was previously installed, upgrading to this release or later on Debian or Ubuntu systems could cause the DHCPv6 and/or the DDNS server, as well as the open source hooks, to be removed.
Fancier Client Options
We have done a lot of work to extend support for those of you with complex device options, adding support for vivco sub-options with multiple different enterprise IDs, for example. The Discovery of Network-designated Resolvers (DNR) options have been implemented for both DHCPv4 and DHCPv6. This is an implementation of the draft-ietf-add-dnr-16 IETF Internet Draft, which is expected to be published as an RFC soon. The options allow configuration of DNS over various transports, such as TLS (DNS-over-TLS or DoT), HTTPS (DNS-over-HTTPS or DoH), and others.
ISC DHCP Work-alike Features
We added affinity for already-released leases, “early allocation” of addresses during DHCPOFFER, and the ability to cap setting the DNS time-to-live (TTL) as a percentage of a lease lifetime. All of these were features of ISC DHCP that have been requested by Kea users. We have also added support for a new feature called “template classes,” which is similar to the “spawning classes” feature in ISC DHCP.
Configuration Management
A number of changes make configuration management easier, including a configuration hash function that makes it easy to tell whether the configuration has changed, new commands for querying and updating host reservations, an audit trail in the forensic log to show changes made administratively, and a major update to Kea’s YANG and Sysrepo support.
For a complete list of new features, please check out the Kea 2.4.0 Release Notes.
Kea Hooks Basic Commercial End User License
You may not have noticed that last year we updated the basic commercial license for the non-open source hooks. (The open source hooks remain licensed under MPL 2.0; this is unchanged.)
The Premium hooks package, purchased online without support, is now for smaller businesses and non-profits only. There are 12-month license subscription options for 1,000, 6,000, 15,000, and 30,000 active leases at prices starting at $549. We think it is fairer for large enterprises and service providers to pay more, but we also wanted to preserve a low-cost option for universities and other non-profits, so qualifying organizations can purchase the lowest-cost option for up to 30,000 active leases.
Larger deployments can access the Premium and Subscriber hooks as a bundle, either without support at the Basic level, or with support at Bronze, Silver, or Gold levels. Our levels are:
- Basic - premium and subscriber hooks; advance security notifications (ASNs); no support
- Bronze - premium and subscriber hooks; ASNs; email support during business hours
- Silver - premium, subscriber, and the new RBAC hook; ASNs; 24x7 email and phone support with SLAs
- Gold - premium, subscriber, and the new RBAC hook; ASNs; 24x7 email and phone support with faster response times
Our support prices are based on deployment size, as measured by the number of simultaneous leases provided. For more information on the support options, please see our Support page and our Kea Support Subscription datasheet.
References
