Stork 2.6 unifies DHCP leases and DNS transfer tracking

Stork 2.6 expands the open-source management tool with consolidated Dynamic Host Configuration Protocol (DHCP) lease tracking and Domain Name System (DNS) zone-transfer monitoring. DHCP automatically assigns network addresses to devices, while DNS directs internet names to the systems that serve them. ISC describes version 2.6 as a stable release suitable for production use, although it also identifies two known issues that administrators should review before deployment.

The release has four main additions: tracking leases across multiple Kea DHCP servers, authentication through OpenID Connect, monitoring BIND 9 DNS zone transfers, and support for the Kea Configuration Backend. ISC has also replaced a major user-interface dependency and introduced several security-related changes.

Consolidated lease tracking is intended to give administrators one view of address assignments across a potentially large Kea deployment. A lease is the temporary assignment of an IP address to a device. When the feature is enabled, Stork agents collect lease information from the lease files of detected Kea instances and send it to the central server. Stork then creates a searchable database covering leases from all monitored servers. The current implementation works only with Kea's memfile backend, which stores lease data in files.

Administrators can sort, filter and search the collected leases, including DHCPv6 leases used with the newer version of the Internet Protocol, and open an individual record for more detail. ISC says the broader project is intended to help operators see which clients hold leases, investigate allocation problems, locate leases belonging to a particular client, review a client's lease history, identify devices receiving a lease for the first time, and speed up early renewal or removal in specific circumstances. Not all of those goals are described as completed features in this release. ISC is seeking further use cases to guide future diagnostics, particularly for networks with many subnets and large numbers of leases.

The second major change is OpenID Connect (OIDC), a standard that lets one service rely on an external identity provider to confirm who a user is. Stork previously supported credentials stored in its own database and LDAP, a system commonly used to maintain organizational user accounts. With OIDC configured, the Stork server acts as a relying party and hands authentication to an external provider. This can connect the application to Single Sign-On (SSO), where one organizational account is used across services, and allows the external provider to require multi-factor authentication.

For DNS operators, Stork 2.6 introduces centralized BIND 9 zone-transfer monitoring. A zone transfer copies authoritative DNS records, meaning the records that provide the official answers for a domain, between DNS servers. Diagnosing a stuck or stalled transfer has traditionally required operators to examine BIND logs and assemble information from multiple places.

Stork agents can now retrieve records of started, completed and failed transfers from multiple BIND 9 instances. The server correlates those events and presents one list for the monitored environment. Each record has a timestamp with millisecond precision and can show the start time, duration, sending server and receiving server. For failed transfers, Stork can expose additional detail taken from the relevant log messages. This gives operators a direct way to distinguish successful synchronization from transfers that did not finish.

The release also makes Stork compatible with the Kea Configuration Backend, which stores almost all Kea configuration in one or more databases. Its potential advantages include reusing identical configuration sections across servers, maintaining one source of truth, applying changes through an API with real-time logic checks, integrating third-party tools or internal automation, and using database properties for concurrency, consistency and atomic changes. The database can also support reporting and replication for real-time fault tolerance.

ISC also notes trade-offs. Adopting the backend can require substantial preparation for integration or automation, supported scenarios require most configuration work to go through the API, and that API is available only to ISC customers with a paid support contract. Earlier versions could not use Stork to manage configurations held in this backend.

Stork 2.6 can create, change and delete backend-stored subnets when the `cb_cmds` and `subnet_cmds` hook libraries are loaded. A subnet is a defined portion of an IP network, while a hook library extends Kea with additional commands or behavior. Daemons using the same backend database and server tag are grouped in the subnet form so that an administrator cannot configure them individually in inconsistent ways. Administrators can choose the server tags associated with a subnet, which determines which servers receive it. Help text distinguishes operations that alter the JSON configuration file from those that change the backend database.

ISC has replaced PrimeNG, the interface component library previously used for tables, pagination, buttons and other controls. PrimeTek announced at the end of June that it would stop work on the open-source PrimeNG library and move to a commercial model. ISC considered maintaining selected components itself, switching to Angular Material, and rebuilding the interface with HTMX. It ultimately adopted Optimus-UI, an open-source community fork maintained through OpenNG, and says it is budgeting for an annual financial contribution to that organization.

On security maintenance, the Stork team is experimenting with weekly dependency updates in response to the volume of vulnerabilities reported across its software ecosystem. ISC says version 2.6.0 also contains other security improvements and fixes documented in its release notes. Because two known issues remain, administrators should read both the release notes and the Stork Known Issues List, test the upgrade against their own configuration, and retain a recovery path before using it in production.

Source code is available through ISC's downloads area. ISC also distributes packages for Debian, Alpine and RPM-based systems through its Cloudsmith repository, with a Quickstart Guide and Administrator Reference Manual available for deployment guidance. Professional Stork support is offered as an item on a Kea DHCP support contract. ISC lists Bronze with business-hours email support, Silver with round-the-clock email and telephone support under service-level agreements, and Gold with faster response times. Silver and Gold include the Role-Based Access Control hook, and subscription cost is based on deployment size measured by simultaneous leases.

For organizations that need outside help operating systems such as these, AEU-I provides security-first IT, infrastructure and consulting.