DHCP Server

A Sysadmin managing an office network with fifty Developer laptops, several printers, and dozens of other User devices faces the reality that these devices connect and disconnect every day. Assigning IP addresses manually to each device one by one is not only exhausting, but also prone to human error, such as two devices receiving the same IP address and clashing on the network. This is where DHCP (Dynamic Host Configuration Protocol) takes over that task automatically by providing the correct network configuration to every connected device without any manual intervention.

This chapter continues the network discussion from Chapter 9 and closes the DNS-DHCP material series as two core services that almost always run side by side on any network. We will start from the concept of DHCP and leases, move on to the installation and configuration of a modern DHCP server, IP reservations based on MAC addresses for devices that need fixed addresses, and conclude with the concept of DHCP integration into DNS via dynamic DNS updates.

10.1 DHCP and Lease Concepts

DHCP is a network protocol that automatically provides IP address configuration, subnet mask, default gateway, and DNS servers to devices newly connected to the network. Instead of the Sysadmin typing the IP configuration one by one on every Developer laptop or User device, the DHCP server stores and distributes this configuration centrally from a single place.

The most important concept we need to understand here is the lease. The DHCP server does not give clients permanent ownership of an IP address, but merely "loans" it for a specific period of time. Before that loan period expires, the client must renew its request if it still wants to use the same IP address. Otherwise, that IP address returns to the pool and another device can use it. This scheme is especially important on networks with many devices dynamically connecting and disconnecting, such as User laptops toggling active and inactive, or guest devices on the office Wi-Fi network.

This IP address assignment process happens through four stages known by the acronym DORA:

• Discover: a client that has just booted up sends a broadcast across the network to search for active DHCP servers.
• Offer: the DHCP server receiving the request replies with an offer of one IP address from the available pool.
• Request: the client selects one of the offers (usually the first one received) and formally requests it.
• Acknowledge: the DHCP server confirms the assignment of that IP address while sending additional parameters, such as the gateway and DNS servers.

This entire DORA process runs on top of UDP, with the DHCP server listening on port 67 and the client listening for responses on port 68. According to official Ubuntu Server documentation, we can combine the following three address allocation schemes based on network needs:

• Dynamic allocation: the DHCP server provides an IP address from a pool for a specific lease duration, then reclaims it back to the pool after the lease expires or the client leaves the network. Sysadmins most frequently use this scheme for User laptops and guest devices.
• Manual allocation: the DHCP server recognizes each device's MAC address and always provides the same IP address to that device, although still through the DHCP mechanism. Section 10.3 uses this scheme for IP reservations, suitable for printers or internal servers that require consistent addresses.
• Automatic allocation: similar to dynamic allocation, but once the DHCP server assigns an IP address to a device, that device tends to keep using the same IP address for a very long period or indefinitely.

Understanding these concepts is sufficient preparation to move on to practical installation. One important point we need to clarify first is which DHCP server package is relevant to use on Ubuntu Server 26.04 LTS.

10.2 DHCP Server Installation and Configuration with Kea

Many Linux DHCP tutorials and learning materials still direct readers straight to isc-dhcp-server. For years, that package was indeed the standard DHCP server in the Linux world. However, Sysadmins must know one critical development before installing any package: the ISC (Internet Systems Consortium), as the developer of isc-dhcp-server, officially declared the software end-of-life as of October 2022 and stopped developing it. Following up on that decision, Ubuntu marked the isc-dhcp-server package as deprecated and no longer supported starting with the Ubuntu 24.04 LTS release, so its status remains the same on version 26.04 LTS.

Ubuntu recommends Kea, a DHCP server also created by ISC, as its official replacement. Kea is designed to be more modern: JSON-based configuration, REST API support for management, and re-configuration support without requiring a full restart. Therefore, this chapter uses Kea as the DHCP server, instead of isc-dhcp-server which is still widely mentioned in older references. Sysadmins coming across isc-dhcp-server tutorials on the internet need to realize that those guides refer to unmaintained software.

10.2.1 Installing the Kea Package

On Ubuntu Server, kea is a metapackage containing all Kea components at once: kea-dhcp4-server for the DHCPv4 service, kea-dhcp6-server for DHCPv6, kea-ctrl-agent as the management REST API, kea-dhcp-ddns-server for automatic DNS updates discussed in Section 10.4, and kea-admin as the lease database administration tool.

Practical Steps

1. Update the package list, then install Kea.

   sudo apt update
   sudo apt install kea

2. The installation process will display a dialog to set up a password for kea-ctrl-agent authentication. Keep this password safe because we will use it whenever accessing the Kea REST API. The password is stored in /etc/kea/kea-api-password with strict permissions; only root and the _kea group can read it.
3. Check the installed Kea version. Always verify this version directly on the server because package versions can differ between Ubuntu releases.

   kea-dhcp4 -v
   dpkg -l kea

4. This chapter focuses on DHCPv4, so ensure kea-dhcp4-server runs automatically and is active during the boot process.

   sudo systemctl status kea-dhcp4-server
   sudo systemctl enable kea-dhcp4-server

5. If the managed network does not yet require DHCPv6, disable that service so as not to increase the attack surface without benefit.

   sudo systemctl disable --now kea-dhcp6-server

Verification and Troubleshooting

• Ensure kea-dhcp4-server is listening for DHCP requests on port 67/UDP.

  sudo ss -lnup | grep kea-dhcp4

• Open port 67/UDP on UFW so clients on the network can send DHCP requests to this server.

  sudo ufw allow 67/udp

• In the field, the most common mistake at this stage is not about installation, but about network topology. Never activate a new DHCP server directly on a production network that already has another active DHCP server (such as a home or office router). Two DHCP servers active simultaneously within a single broadcast domain will respond to client requests at the same time, triggering confusing and hard-to-trace IP address conflicts. Test first in a laboratory network or an isolated VLAN before using it in a production environment.

10.2.2 The kea-dhcp4.conf Configuration Structure

Unlike BIND9 which uses its own distinct configuration syntax, Kea uses the JSON format for all its configuration files. The main configuration file for the DHCPv4 service is located at /etc/kea/kea-dhcp4.conf, and the entire configuration resides inside a single large object named Dhcp4.

Practical Steps

1. View the default contents of kea-dhcp4.conf before making changes to understand its basic structure.

   cat /etc/kea/kea-dhcp4.conf

2. Notice several key fields present by default:

   {
     "Dhcp4": {
       "interfaces-config": {
         "interfaces": [ "eth0" ]
       },
       "control-socket": {
         "socket-type": "unix",
         "socket-name": "/run/kea/kea4-ctrl-socket"
       },
       "lease-database": {
         "type": "memfile",
         "lfc-interval": 3600
       },
       "valid-lifetime": 600,
       "max-valid-lifetime": 7200
     }
   }

   interfaces-config specifies the network interface on which Kea listens for DHCP requests. Adjust its value to match the actual server interface name (check using ip a). A lease-database of type memfile means Kea stores lease data as a local CSV file, which is sufficient for most small-to-medium networks without needing an external database. valid-lifetime represents the lease duration in seconds. The value of 600 seconds in this example is only suitable for testing, whereas production networks typically use much longer values, such as 43200 (12 hours) or 86400 (24 hours).

Verification and Troubleshooting

• The most common error in JSON files is unbalanced curly brackets or commas. Kea rejects syntactically invalid configurations, and we will validate it explicitly in Section 10.2.3 before applying it.
• We can directly inspect stored lease data to audit who has received an IP address from this server.

  cat /var/lib/kea/kea-leases4.csv

10.2.3 Subnets, Pools, and Network Options

The default configuration does not yet define the network to be served. The subnet4 section is where we define the network, the assignable IP address range (pool), and additional options such as gateways and DNS servers sent to clients.

Practical Steps

1. Add a subnet4 block inside kea-dhcp4.conf. The following example uses network 192.168.1.0/24 with a dynamic pool from .100 to .200. Adjust this configuration according to your network scheme.

   sudo nano /etc/kea/kea-dhcp4.conf

   {
     "Dhcp4": {
       "interfaces-config": {
         "interfaces": [ "eth0" ]
       },
       "control-socket": {
         "socket-type": "unix",
         "socket-name": "/run/kea/kea4-ctrl-socket"
       },
       "lease-database": {
         "type": "memfile",
         "lfc-interval": 3600
       },
       "valid-lifetime": 43200,
       "max-valid-lifetime": 86400,
       "subnet4": [
         {
           "id": 1,
           "subnet": "192.168.1.0/24",
           "pools": [
             { "pool": "192.168.1.100 - 192.168.1.200" }
           ],
           "option-data": [
             { "name": "routers", "data": "192.168.1.1" },
             { "name": "domain-name-servers", "data": "192.168.1.10" },
             { "name": "domain-name", "data": "example.local" }
           ]
         }
       ]
     }
   }

   The routers option specifies the default gateway, while domain-name-servers points to the internal DNS server built in Chapter 9. This ensures clients automatically use the internal DNS server rather than a public resolver.
2. Validate this configuration syntax before applying it. This habit is just as important as running named-checkconf on BIND9 or netplan generate in Chapter 8.

   sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

3. After successful validation without any Error encountered lines, restart kea-dhcp4-server so Kea applies the new configuration.

   sudo systemctl restart kea-dhcp4-server

Verification and Troubleshooting

• Monitor Kea logs when clients start requesting IP addresses to ensure the DORA process runs correctly.

  journalctl -u kea-dhcp4-server -f

• From the client side (for example, a Developer laptop connected to the test network), renew the DHCP lease request and check the acquired IP address.

  sudo dhclient -r eth0
  sudo dhclient eth0
  ip a show eth0

• Check the recorded leases on the server to ensure the IP address originates from the newly configured pool.

  cat /var/lib/kea/kea-leases4.csv

• If the client fails to obtain an IP address, the most frequent causes are typos in the interface name inside interfaces-config, a mismatch with the physical server interface, or port 67/UDP on UFW not being opened as described in Section 10.2.1.

10.3 IP Reservations Based on MAC Address

Dynamic pools are suitable for User laptops whose IP addresses can change at any time. However, certain devices require a fixed IP address every time they power on, such as office printers, internal servers, or Network Attached Storage devices. Instead of manually configuring a static IP on each of these devices, a Sysadmin can create a reservation on the DHCP server. Devices still request an IP through DHCP as usual, but the server always responds with the same IP address based on that device's MAC address.

Practical Steps

1. Find out the MAC address of the target device by running a command directly on that device.

   ip link show eth0

2. Add a reservations array inside the relevant subnet4 block. Choose an IP address outside the dynamic pool range (for example 192.168.1.50 outside the 100-200 range defined earlier) to avoid conflicts with dynamic allocations.

   {
     "Dhcp4": {
       "subnet4": [
         {
           "id": 1,
           "subnet": "192.168.1.0/24",
           "pools": [
             { "pool": "192.168.1.100 - 192.168.1.200" }
           ],
           "option-data": [
             { "name": "routers", "data": "192.168.1.1" },
             { "name": "domain-name-servers", "data": "192.168.1.10" }
           ],
           "reservations": [
             {
               "hw-address": "aa:bb:cc:dd:ee:01",
               "ip-address": "192.168.1.50",
               "hostname": "printer-lantai2"
             }
           ]
         }
       ]
     }
   }

3. Validate, then restart Kea as usual.

   sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
   sudo systemctl restart kea-dhcp4-server

Verification and Troubleshooting

• Request the device with that MAC address to renew its lease, then confirm that the obtained IP address matches the reservation.

  sudo dhclient -r eth0
  sudo dhclient eth0
  ip a show eth0

• If the obtained IP address still comes from the dynamic pool instead of the reservation, recheck the hw-address formatting. An invalid MAC address format (such as wrong delimiter characters or letter casing mismatches with Kea records) prevents the reservation from matching. As a result, Kea automatically assigns an IP address from the pool as if no reservation existed.
• Always place reserved IP addresses outside the dynamic pool range, as shown in the example above. If a reservation sits inside the pool range, Kea risks leasing that IP address to another device before the reservation owner gets a chance to connect, especially on high-traffic networks.

10.4 Integrating DHCP with DNS: Dynamic DNS Update Concepts

Up to this section, DHCP and DNS still run as two separate services: DHCP distributes IP addresses, while the Sysadmin manually fills in DNS zone files from Chapter 9. The issue is that if a Developer laptop's IP address changes via the dynamic pool, the DNS record for that device quickly becomes stale if the Sysadmin has to update it manually every time a lease changes.

Dynamic DNS update (defined in RFC 2136) solves this problem by allowing the DHCP server to automatically notify the DNS server whenever it grants or revokes a lease, keeping the A and PTR records in the DNS zone updated automatically without manual intervention. In the Kea ecosystem, the component handling this role is called kea-dhcp-ddns-server (often abbreviated as D2), which was installed as part of the kea metapackage in Section 10.2.1.

Broadly speaking, the workflow is as follows: whenever kea-dhcp4-server grants or revokes a lease, that service sends a change request (called a NameChangeRequest) to D2. D2 then constructs the appropriate DNS update and sends it to BIND9 from Chapter 9. To prevent BIND9 from accepting updates from unauthorized parties, the Sysadmin secures this communication using TSIG (Transaction Signature), a shared secret key ensuring BIND9 only trusts updates originating from a legitimate D2.

On the Kea side, we can enable sending these updates and specify the domain suffix to use by adding the following block to kea-dhcp4.conf:

{
  "Dhcp4": {
    "dhcp-ddns": {
      "enable-updates": true
    },
    "ddns-qualifying-suffix": "example.local"
  }
}

The complete configuration involves creating a TSIG key, adjusting named.conf on the BIND9 side to allow updates from that key, and configuring kea-dhcp-ddns-server itself. This topic is extensive and falls outside the scope of this chapter. The main takeaway to understand at a conceptual level is that DHCP-DNS integration is not an unconditioned automatic process, but rather the result of two services mutually trusting each other through clear authentication mechanisms. Understanding this type of trust relationship is extremely useful when Sysadmins deal with broader infrastructure automation.

At this point, we have mastered DHCP from core concepts and the DORA process, the reasons for choosing Kea to replace the deprecated isc-dhcp-server, installing and configuring subnets along with pools, IP reservations based on MAC addresses, up to an overview of integration concepts with DNS via dynamic updates. Chapter 11 will discuss another network topic that often gets overlooked yet is crucial for services like DHCP and DNS: time synchronization using chrony.