Connecting

In early October 2022, the Internet Systems Consortium (ISC) released versions 4.4.3-P1 and 4.1-ESV-R16-P2 of the ISC Dynamic Host Configuration Protocol (DHCP) server. At the same time, the non-profit organization announced that this would likely be the last release of the software and set the end-of-life date for December 2022. Although the DHCP server daemon dhcpd remains functional, according to ISC it will no longer be updated unless serious security vulnerabilities arise. Now is the time therefore for you to take a look at Kea, ISC's new DHCP server suite.

Development of the designated dhcpd successor began in 2014. At the time of writing, the available Kea versions were 2.2.0 (July 2022, Current-Stable) and 2.3.6 (March 2023, Experimental-Development). Most distributions have prebuilt Kea packages in their repositories, and the ISC itself offers its own DEB, RPM, and APK packages. A source code tarball is available for download, as well.

Structure

Under the auspices of the legacy ISC dhcpd, IPv4 and IPv6 DHCP were still completely separate processes with completely separate configurations. Kea still maintains two separate services with separate configuration files, but a single Kea control agent controls them. A REST API can also be used to configure services consistently. The fourth component is the dynamic DNS (DDNS) update daemon, which creates entries on DNS servers on the basis of assigned DHCP leases. This function was already part of the classic ISC dhcpd.

The way data is stored is another major difference. The ISC dhcpd allowed LDAP as an external data source. Kea supports PostgreSQL and MySQL databases for lease and host reservations. However, the Kea administrator's guide advises creating host reservations in the configuration file so that perfomance is not affected, unless large volumes are involved. Without the database, the host reservations reside directly in the configuration file, and Kea manages the leases in a CSV file.

The Kea design is modular, so you first need to load custom libraries to enable certain functions (e.g, to support the back-end database and to enable REST API commands for managing leases).

Installation

The easiest way to install Kea is to use Apt, Yum, Emerge, or Pacman. If your choice of distribution does not give you the version you want, use the ISC repositories [1]. Depending on the distribution (e.g., Ubuntu), the various components are also available as individual packages.

First, you need to decide which of the components to run. If you do not use IPv6, the DHCPv6 server does not need to be running. Likewise, the DDNS updater does not need to run if the infrastructure does not require it. Here, too, the procedure differs from distribution to distribution. Ubuntu, for example, has one systemd service per component. On Gentoo Linux, entries in the /etc/conf.d/kea file control the components started by the kea service.

Configuration

The most essential difference from dhcpd is the format of the configuration file: Kea relies on JSON. The basic syntax has been standardized. Individual components each have their own configuration file, which is always structurally similar. The outermost block is a JSON dictionary that contains the file type or configuration as a single key. The DHCP configuration in IPv4 and IPv6 uses dhcp4 and dhcp6, whereas Control-agent is for the control agent. Listing 1 shows a very simple configuration for the DHCP4 daemon.

"Dhcp4": {
 "interfaces-config": {
  "interfaces": [ "eth0" ]
 },
 "control-socket": {
  "socket-type": "unix",
  "socket-name": "/run/kea/kea4-ctrl-socket"
 },
 "lease-database": {
  "type": "memfile",
  "lfc-interval": 3600
 },
 "renew-timer": 900,
 "rebind-timer": 1800,
 "valid-lifetime": 3600,
 "option-data": [{
  "name": "domain-name-servers",
  "data": "192.168.2.1, 192.168.2.2"
 }, {
  "name": "domain-search",
  "data": "mydomain.example.com, example.com"
  }],
 "subnet4": [{
  "subnet": "192.168.2.0/24",
  "pools": [{"pool":"192.168.2.1 - 192.168.2.50"}],
  "option-data": [{
   "name: "routers",
   "value": "192.168.2.254"
   }],
  "reservations": [{
   "hw-address": "00:11:22:33:44:55",
   "ip-address": "192.168.2.60",
   hostname: "host-2-60"
   }, {
   "hw-address": "00:00:00:00:00:01",
   "ip-address": "192.168.2.253",
   hostname: "special-host",
   "option-data": [{
    "name": "domain-name-servers",
    "data": "192.168.1.1"
   }]
  }]
 }]
}

This example defines the service for the 192.168.2.0/24 subnet. The DNS servers on this network have the IP addresses 192.168.2.1 and 192.168.2.2, and you want the clients to look for host records in the mydomain.example.com and example.com domains. The configuration defines a subnet (subnet4, 192.168.2.0/24) for which the default router option applies with a router on 192.168.2.254. On this network, dynamic IP addresses are assigned from a pool ranging from 192.168.2.1 to 192.168.2.50. Finally, two reservations on this subnet are based on the MAC address. A specific DNS server is explicitly set for the second reservation.

The entire configuration uses the in-memory database stored in a CSV text file for the assigned leases. Its location depends on your choice of distribution, but it will typically reside in /var/lib/kea/. The configuration structure is logical. The block option-data appears at three different hierarchy levels, but it is always a field with single dictionary entries. Instead of the name keyword, an entry can also use code followed by the number of the configured DHCP option. For example, the block from Listing 2 sets DHCPv4 option code 15 (domain-name).

{
 "code": 15,
 "data": "example.org" }

The more specific the hierarchy, the higher the priority. A host-level option overrides the subnet-level definition, which in turn overrides a global definition. The control-socket block defines the "remote control." This Unix domain socket supports commands from Kea's REST API. With a tool like socat, you can send API commands directly in JSON format if needed. The Kea Control Agent component essentially translates this access to an HTTP interface and allows access to all other components, each of which provides its own control socket.

In more complex DHCP configurations, classes often group hosts together according to certain parameters besides the logical Global, Subnet, and Host hierarchy levels. For a class of this type, you can then use an option-data block to set other options. This is required to boot off the network, for example. Boot agents usually send their own parameters in the DHCP request.

In the case of classic PXE boot, a string like PXEClient:Arch:00000:UNDI:002001 is found in the vendor-class-identifier option. In a class that checks this option, the client then needs to download parameters like the boot file by trivial FTP (TFTP). If the client boots its operating system from the local hard drive, it is not usually necessary to specify a network boot file, which, accordingly, does not need to be sent. The Kea configuration defines classes under the client-classes key.

Listing 3 shows a block that implements the described scenario for TFTP-based booting. The syntax of the possible tests is described in a Knowledgebase article from the ISC [2].

"client-classes": [{
 "name": "pxeplain",
 "test": "option[vendor-class-identifier].text == 'PXEClient:Arch:00000:UNDI:002001'",
 "next-server": "172.17.1.1",
 "boot-file-name": "pxelinux.0"
}]