DNS & DHCP spotlight: BIND 9.14 & Kea

While we were at RIPE 78 in Reykjavik, we got to catch up with Matthijs Mekking, a software engineer at ISC tasked with working on BIND, DNSSEC and other projects. We made a podcast of our chat, but given just how important BIND is to everyday workflows, a blog post touching on some of the topics also seemed warranted.

BIND 9.14

BIND truly is one of the most fundamental pieces of software for anyone working with DNS. (It’s not for no reason that we call our training program DNS & BIND!)

Changing the BIND release scheme

Starting with BIND 9.13, ISC has changed the release schedule for BIND, where odd numbers represent development releases, and even numbers note the stable branch. Users welcomed the opportunity to test the development branch; and since many companies build on BIND's features, these versions offer a chance to strategize. It also allows ISC to gather valuable early feedback and enables them to better focus their resources or course correct where necessary. (Find out which version of BIND 9 suits you best)

What's new in BIND 9.14

With BIND 9.14, ISC focused on making BIND a modern nameserver again. In addition to bug fixes, this includes responding to privacy and usability requests, including:

• a lot of modernization and code refactoring
• 12% performance increase
• QNAME minimization (and enabled by default in relaxed mode) for enhancing privacy
• mirror zones (serving a transferred copy of a zone’s contents without acting as an authority for it)

What's coming in BIND 9.15

In BIND 9.15, ISC will continue to modernize BIND's codebase, in particular refactoring the networking code. This will allow them to streamline implementations such as DNS-over-TLS and DNS-over-HTTPS and make them easier to deploy.

Making DNSSEC in BIND more intuitive is also a priority. This includes making DNSSEC easy for signing purposes as well as providing support for offline and combined signing keys.

These roadmap plans should form a solid base for BIND 9.16, which is scheduled to be the next Extended Support Version (ESV) after BIND 9.11.

Kea

As mature and robust as ISC DHCP is, it's also old. It was started in 1995, when networks were a lot smaller and network management a lot more straightforward, and perhaps not as integral to the success of business operations as it is today. ISC DHCP code was extended through the years, but that also made it harder to maintain.

Kea DHCP came alive as the natural successor to ISC DHCP, designed for modern mission-critical environments and destined to address these issues. It's a more scalable and better performing DHCP server, with a different architecture and a somewhat different feature set. (Such as new features coming with hooks and a rich API to configure users and subnets, radius integration, and support for several database backends.)

ISC recommends, particularly for new deployments, to use Kea instead of ISC DHCP. This is not only because Kea is better adapted to modern environments, but also because support for ISC DHCP will cease in the long term, most likely any time after 2020.

To learn more about Kea and how to migrate from ISC DHCP, take a look at this webinar from ISC:

Kea's modules vary from open source to paid (freemium and subscription) but the documentation for all modules is freely available for users to look at and evaluate. Beta versions are also freely available.

Where to from here?

As BIND and Kea shows, development in the network infrastructure (DNS, DHCP, IPAM) space is not only ongoing but vibrant. RIPE78 (as with all RIPE AGMs) provided a great opportunity for a glimpse at just how vibrant this sector is.

As a company wholly dedicated to DDI, we're following developments at ISC and other major developers continuously, and share what we learn along the way. For example, both our RIPE 78 blog coverage and our newly launched podcast focus on the details and implications of major changes that are happening or are expected to happen. Follow us here on our blog, on social, and subscribe to the podcast to stay in the know.