2025 Stork, Kea, and DHCP Development Report

Tomek Mrugalski, Director of DHCP Development leads the combined Stork, Kea and DHCP team.

Four Software Engineers work on Kea:

• Marcin Siodelski - Kea and Stork
• Thomas Markwalder - Kea and KeaMA
• Razvan Becheriu - Kea
• Francis Dupont - Kea and KeaMA

The Stork team includes three Software Engineers:

• Sławek Figiel
• Piotrek Zadroga
• William Leuschner

Włodek Wencel is our DHCP QA manager, and his team includes:

• Andrei Pavel - QA Engineer
• Marcin Godzina - QA Engineer
• Emanuel Petr - Systems Administrator
• and we have one open position!

What does the team do?

The primary focus of the team is:

• Fixing bugs in the Kea DHCP system
• Developing features in our Stork management tool
• Writing, and running, a lot of tests, and analyzing the results
• Producing regular monthly development releases and annual new stable versions

The team maintains 22 repositories on GitLab, including both our public and non-public work. There is a little activity surrounding our legacy support for ISC DHCP, which is EOL, but we still have a few customers we provide EOL support to. In 2025 we are making a few improvements to our KeaMA migration utility for ISC DHCP users, which we maintain as an on-line service, in addition to publishing the source code.

The team is particularly focused on addressing user and support subscriber requests. This includes:

• Triaging, discussing user-created issues on GitLab
• Reviewing PRs on Github and GitLab
• Responding to questions on our Kea and Stork user mailing lists

The QA team specifically is engaged in:

• Designing, writing and maintaining system tests.
• Managing continuous integration testing in Jenkins and pipelines in GitLab
• Release engineering for Kea and Stork
• Building packages, Docker containers, conducting testing, reviewing rest results, and assessing vulnerability reports.
• The QA team also manages multiple package repositories on Cloudsmith.
• The Kea and Stork continuous integration testing system that QA maintains runs on 6 OSes, 14 different versions, and 2 different architectures.
• There are >500k unit tests for Kea
• There are >30k system tests for Kea
• We run 7 different code analyzers
• In addition, the QA team handles release engineering, which requires building some 900 packages for all the components and operating systems we support.

Kea team achievements in 2025

We issued 14 Kea releases. Three of these were security releases, addressing vulnerabilities in Kea.

In 2025, we had 473 new Kea issues opened, and we closed 309 issues (mostly by fixing bugs or adding features). Of these, there were 42 issues opened on behalf of support customers, and we closed 55 issues for our customers. Overall the Kea project has had 3992 issues opened, has closed 3198 issues, and has 794 remaining open as of this writing.

Ongoing maintenance and development continued through the 2.7.x development stream in 2025. We expanded API command capabilities (e.g., returning shared network names in list output), added syslog support for advanced log hooks, and resolved lease handling edge cases with database backends. We transformed our database backend support into hooks, to reduce the code exposure for users not choosing to use MySQL/Maria or Postgres and to enable advanced users to implement their own hooks to support other databases if needed.

In mid-year, we released Kea 3.0, our first long-term support version. This release marked a significant evolution beyond the 2.x stable series, with a planned three-year support lifecycle that gives enterprise users more stability and fewer upgrades compared with the previous annual release cadence. Kea 3.0 open-sourced many components that were previously commercial-only — ISC moved twelve hook libraries into the open-source tree, making popular features like host reservation management and subnet configuration accessible without proprietary licenses. (Two of these, the Configuration Backend and RBAC hook libraries, remain under a commercial license and are shared with support customers only.)

Kea skipped a 2.8 version entirely to emphasize the extent of the changes and the need for operators to consult the detailed release notes to manage configuration adjustments during upgrade. New installation packaging simplified deployment by consolidating hook libraries into the standard distribution, and major architectural improvements such as integrated HTTP/TLS API sockets replaced the legacy Control Agent for remote management, reducing complexity and opportunities for mis-configuration. Kea 3.0 included a major uplift to client classification, implementing option-class-tagging, which we expect will be very popular. The build system was modernized by migrating to Meson, which improves maintainability and speeds up development workflows. At the same time Kea continued to bake in security hardening with updated defaults, stricter file and socket handling, and security fixes in the 2.6.x series which addressed multiple security vulnerabilities affecting API accessibility and file handling (listed below).

Kea and Security

In May, we received an alarming new confidential issue, from Matthias Gerstner from the SUSE security team. He had done an extensive review of Kea installation and identified several vulnerabilities in Kea, including CVE-2025-32802: Insecure handling of file paths allows multiple local attacks, CVE-2025-32803: Insecure file permissions can result in confidential information leakage, and https://kb.isc.org/docs/cve-2025-32801. These were the first reported CVEs in Kea since 2019, and they were quite a wakeup call for us. In addition, Matthias pointed out other, less serious issues and made some recommendations for improvements in Kea’s integration with the operating system environment. We spent quite a bit of time reviewing the report and, of course, discussing approaches to better securing Kea.

We had two other CVEs in 2025:

• CVE-2025-40779: Kea crash upon interaction between specific client options and subnet selection and
• CVE-2025-11232: Invalid characters cause assert

Towards the end of the year, we underwent our first formal external security audit, by Ada Logics. (The final report is awaiting publication by the auditors.) The project included development of a threat model for Kea, manual code inspection, establishment of a fuzz-testing project on Google’s OSS Fuzz project, and analysis with a range of tools. Following the audit, the Kea team adopted the auditors’ Google OSS fuzz project, for an on-going boost in our fuzz testing coverage, and we are looking at adopting some of the analyzers they recommended as well.

Together, these accomplishments in 2025 reflect a transition year for Kea: from an annually-updated stable series to a long-term supported platform with broader open-source access to advanced features, tighter security postures, and modernized build and remote management capabilities, while continuing incremental improvements in the development branch in response to user requests.

Kea 2026 Development Plans

In 2026 we will continue to prioritize feature requests from our support customers and open source user base. We plan to implement Active Leasequery, the last major RFC feature that we don’t support yet in Kea. We will improve interface detection, and investigate our options for better handling of high-traffic, overflow situations. We are looking at integration with scalable industry-leading solutions for user authentication and authorization, possibly via Stork. We are working on a solution to the well-known Blast Radius protocol vulnerability. We will produce another short-lived (1 year) stable version for those users who need to deploy the latest features.

Although we do not yet have user requests for this, we expect to implement SBOMs for Kea packages and establish SLSA (supply chain security) documentation, and otherwise, prepare for the implementation of the EU Cybersecurity Regulation (CRA) in 2027. We are also working on a solution to the well-known “Blast Radius” protocol vulnerability.

ISC DHCP to Kea Migration support

We are updating the KeaMA tool for migration from ISC DHCP to Kea, mostly to reflect features that were previously missing in Kea, that have since been added. We continue to maintain an on-line hosted version of KeaMA which is used daily by anonymous users to translate ISC DHCP configuration files into Kea configurations. The translated configuration still requires review and editing. ISC made a mistake in 2006 in ISC DHCP (we implemented an “interim” TXT record, while waiting for the DHCID RR to be specified). The final specification became available a couple months later, but since then, we, and our users, have been stuck with the legacy of this interim implementation in ISC DHCP. Kea does it properly: in Kea we implemented the standard DHCID only, but ISC DHCP users adopting Kea are once again having to deal with the legacy implementation in ISC DHCP.

Stork 2025 achievements

We released 8 versions of Stork including a special release for 1 security vulnerability, addressed in Stork 2.3.1. 227 new issues were opened, and 246 issues closed. (Of course, these issues ranged from minor documentation fixes to significant new development work.)

The development team drove two humongous refactoring projects in Stork. These were: – A major PrimeNG library upgrade (329 files, +9.3kloc, -9.3kloc). – The restructuring necessitated by the removal of the Control Agent from Kea. The Control Agent was terminating all the connections to Kea from Stork, so application communications had to be re-implemented. (322 files, +24kloc, -18.6kloc)

Security fixes in the 2.6.x series addressed multiple security vulnerabilities affecting API accessibility and file handling (listed below).

• CVE-2025-8696, and
• CVE-2024-44905

We also fixed a significant DB exhaustion bug.

7A Security conducted an audit of Stork, specifically focused on penetration testing the application and apis. They also reviewed Stork dependencies, generated an SBOM and made recommendations for achieving SLSA compliance.

Major New Features Added

Marcin Siodelski moved from the Kea team to focus on adding DNS support to Stork.

DNS Support added in 2025:

• The zone list is retrieved from multiple servers, aggregated, and cached in Stork.
• The administrator can view zones, search and sort them, and view zone resource records.
• We have tested retrieving zones from PowerDNS and well as from BIND 9. Marcin attended the DNS hackathon in Stockholm, where he was able to advance Stork’s support for PowerDNS.
• Stork now has a BIND configuration viewer, in addition to the zone viewer.
• We have expanded the Prometheus statistics exporter for BIND.

• We now provide information on the current Kea and Stork software versions in the UI, and alert users if they are using an out of date, or known-vulnerable version of our software,
• Our last release of 2025 added support for communicating with Kea 3.0, without relying on the Control Agent (which has been deprecated).
• We have begun work on adding a comprehensive view of all current leases, across all Kea servers. The design for Lease Tracking is available in Stork’s developer wiki on GitLab.

One new feature that is a big improvement for usability, is the ability to sort the data displayed in table form.

2026 Stork Development Plans

We have ambitious plans for Stork in 2026. We hope to add standard Oauth authentication and authorization for Stork users. We want to add SBOM generation with Secure Lifecycle Software Artifacts (SLSA) documentation. We are already well underway on adding centralized DHCP lease tracking, but there is more work to do to make this feature deployable at scale. We will start adding BIND 9 configuration support, starting with zone provisioning. We have to continue monitoring our external dependencies, which have the potential to cause Stork vulnerabilities, while we extend and improve our QA coverage. We are updating the support for our Kea Migration Agent (KeaMA) tool, as there are still many users still operating ISC-DHCP.

Auto-completion is among many user interface improvements in development.

Community Support for Kea, Stork and DHCP

Our support team has been busy, supporting an increasing number of Kea support customers, and writing and updating technical articles for our knowledgebase. In 2025 we added:

• Things to be aware of when upgrading to Kea 3.0
• Installing the Kea Subscriber Hook Libraries from Sources - Kea 3.0 and later
• Kea Hub and Spoke Experimentation
• Kea Database Connection Resilience
• Limiting DHCP Decline

and a trio of articles on HA strategies:

• Kea HA Strategies Comparison
• Kea Shared Lease Database Quickstart
• Kea HA Quickstart Guide

A few of the updated older documents:

• Kea High Availability vs ISC DHCP Failover
• Securing the MySQL Connection

Miscellaneous other contributions:

• Marcin Siodelski published a new version of his open source DHCP diagnostic utility, Endure
• Vicky Risk gave a talk on the Money and Open-source Sustainability, which was about open-sourcing most of the Kea Premium hooks in Kea 3.0.
• Sławek Figiel made a contribution to the Sphinx project, which we use to generate our documentation.

The Kea-users mailing list is quite active, with a number of users contributing solutions and advice.

Community Acknowledgements

Kea community contributors:

A number of users have opened an issue or two, but a handful of users have made multiple Kea contributions this year, or were particularly helpful:

• Matthias Gerstner from the SUSE security team did us a big favor when he reviewed Kea as part of their packaging process.
• Carsten Strotmann has been our most prolific external contributor to Kea in the past year.
• Philip Prindeville
• Alexander Pankratov
• Dipesh Kayastha
• Chuck Zmudzinsk reported a bug, with a detailed description and a patch.
• Steinar H. Gunderson also submitted a patch (thank you!).

Stork contributors:

• A user named “mikygee” has been testing Stork’s support for DNS, and reporting issues.
• Alex Hautequest made a couple of feature requests, and offered to help implement them!
• Rinse Kloek has been active in GitLab, but also gave a presentation at a NLNOG meeting about his experience migrating Delta Fiber from ISC DHCP to Kea.

In the DHCP industry in general there were two major events in 2025.

– First, Google implemented DHCPv6 in Android. Previously, Android relied on SLAAC for IPv6 address assignment, creating operational challenges for network operators who depend on DHCPv6 for centralized address management, policy enforcement, logging, and compliance. By adding DHCPv6 client support, Google closed a major ecosystem gap and enabled consistent IPv6 operations across mobile, enterprise, and service-provider networks. This change reinforced the practical importance of robust, scalable DHCPv6 servers like Kea.

– Second, RFC 8415 (Dynamic Host Configuration Protocol for IPv6) was formally promoted to Internet Standard status by the IETF. This promotion signified that DHCPv6 is a mature, stable, and widely deployed protocol with proven interoperability. ISC’s two original Kea developers, Tomek Mrugalski and Marcin Siodelski personally invested a lot of time in helping to author RFC 8415, consolidating prior specifications and updates into a single, huge (150 page), authoritative specification.

What about AI use so far in the ISC DHCP team?

Some team members hate it, some love it. The current approach is open-minded: use of AI is permitted. So far we have determined AI is not suited for nuanced protocol development. One developer tried to use duck.ai to generate an example of multi-relay DHCPv6 traffic for documentation and the result was unusable.

We have found that AI can be useful for handling tedious tasks. It can update unit-tests, rewrite something (e.g. rewrite shell script tests in Python). AI was somewhat helpful in fixing a wholesale problem with 3000+ test failing following the Stork application restructuring. We have been using Cursor Bugbot for some reviews and bug detection, although so far we are unimpressed with it.

We are exploring using AI tools in areas where acquiring competence is not essential, such as sporadic changes to the KeaMA web interface. We have experimented with using AI as one of several inputs when evaluating designs and choosing libraries. (Parts of this blog post were initially drafted by AI.)

2026 is promising

ISC took a big commercial risk, open-sourcing so much of the formerly commercially-licensed Kea hook libraries in 2025. The financial fallout from this, so far, has been negligible. The project is currently well-supported with 92 support subscribers, a number which has been growing steadily. With the support of a generous grant, we were able to add two staff to the Stork project in 2025, our first additions in several years. We are excited about our plans for 2026, which will bring significant new DNS and DHCP management features in Stork, as well as a new stable version of Kea, and an updated KeaMA migration tool.