DHCP server configuration is one of those tasks you perform once and forget about -- until it breaks, and then every device on the network loses its address. This article covers both ISC dhcpd (the legacy DHCP server still found in many existing deployments) and Kea DHCP (the modern replacement from the same organization, ISC). Kea is the path forward for new installations: ISC stopped active development of dhcpd and recommends migration to Kea. You need to know both because production environments rarely cut over overnight. Before setting up DHCP, ensure you have a solid grasp of Linux networking fundamentals including IP addressing, subnets, and DNS.
The DHCP Protocol: Understanding the DORA Process
Every DHCP transaction follows four steps, commonly called DORA:
- Discover -- the client broadcasts a UDP packet on port 67 asking "who can give me an IP address?"
- Offer -- one or more DHCP servers respond with an available IP address and lease parameters.
- Request -- the client picks one offer and broadcasts a request for that specific address.
- Acknowledge -- the server confirms the lease and the client configures its interface.
All four messages use UDP. Discover and Request are broadcasts (destination 255.255.255.255), which is why DHCP does not work across routers without a relay agent. The server listens on UDP port 67, the client on port 68.
DHCP lease lifecycle
After receiving an address, the client tracks three timers:
- T1 (renewal timer) -- at 50% of the lease duration, the client contacts the same server that issued the lease and requests an extension via unicast.
- T2 (rebinding timer) -- at 87.5% of the lease duration, if the renewal failed, the client broadcasts a renewal request to any available DHCP server.
- Lease expiry -- if no server responds, the client releases the address and restarts the DORA process.
Understanding these timers explains why a brief DHCP server outage does not immediately cause network disruption -- clients only renew at the T1 mark, giving you time to restore the service.
ISC dhcpd Configuration: The Legacy DHCP Server
ISC dhcpd has been the default DHCP server on Linux for over two decades. Its configuration file is /etc/dhcp/dhcpd.conf (Debian/Ubuntu) or /etc/dhcpd.conf (some RHEL installations). Even though ISC has deprecated it, you will encounter it in existing production environments.
Basic dhcpd.conf configuration
# /etc/dhcp/dhcpd.conf
# Global options
option domain-name "corp.example.com";
option domain-name-servers 10.0.1.10, 10.0.1.11;
default-lease-time 3600; # 1 hour
max-lease-time 86400; # 24 hours
authoritative;
# Subnet declaration
subnet 10.0.1.0 netmask 255.255.255.0 {
range 10.0.1.100 10.0.1.200;
option routers 10.0.1.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.1.255;
}
# Fixed address reservation (by MAC)
host printer-lobby {
hardware ethernet 00:1a:2b:3c:4d:5e;
fixed-address 10.0.1.50;
option host-name "printer-lobby";
}Important details:
authoritative-- tells the server to send DHCPNAK to clients requesting addresses from the wrong subnet. Without this, rogue clients can keep stale addresses indefinitely.- The
rangestatement defines the dynamic pool. Addresses outside this range are available for static reservations. - Fixed-address reservations bind a MAC address to a specific IP. The
hostblock name is arbitrary but should be descriptive.
Start and verify:
# Check syntax before starting
sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
# Start the service
sudo systemctl enable --now isc-dhcp-server # Debian/Ubuntu
sudo systemctl enable --now dhcpd # Fedora/RHEL
# Check lease database
cat /var/lib/dhcp/dhcpd.leasesISC dhcpd failover for high availability
For high availability, ISC dhcpd supports a failover protocol between two servers. Each server is configured as either primary or secondary, and they split the address pool between them:
# On the primary server, add to dhcpd.conf:
failover peer "dhcp-failover" {
primary;
address 10.0.1.5;
port 647;
peer address 10.0.1.6;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
mclt 1800;
split 128;
}
# Reference the failover in the subnet pool:
subnet 10.0.1.0 netmask 255.255.255.0 {
pool {
failover peer "dhcp-failover";
range 10.0.1.100 10.0.1.200;
}
option routers 10.0.1.1;
}The split 128 gives each server half the pool. The failover protocol is proprietary to ISC dhcpd and does not interoperate with Kea.
Kea DHCP4 Server: The Modern Replacement
Kea DHCP is ISC's modern DHCP server, designed from scratch with a modular architecture, JSON configuration, REST API, and database-backed lease storage. On Debian 13.3, Ubuntu 24.04.3, and Fedora 43, Kea packages are readily available. RHEL 10.1 provides Kea in the AppStream repository.
# Install Kea
sudo apt install kea-dhcp4-server kea-admin # Debian/Ubuntu
sudo dnf install kea-dhcp4 # Fedora/RHELKea JSON configuration explained
The main configuration file is /etc/kea/kea-dhcp4.conf. Unlike dhcpd.conf, Kea uses strict JSON:
{
"Dhcp4": {
"interfaces-config": {
"interfaces": ["eth0"]
},
"lease-database": {
"type": "memfile",
"persist": true,
"lfc-interval": 3600
},
"valid-lifetime": 3600,
"max-valid-lifetime": 86400,
"option-data": [
{ "name": "domain-name", "data": "corp.example.com" },
{ "name": "domain-name-servers", "data": "10.0.1.10, 10.0.1.11" }
],
"subnet4": [
{
"id": 1,
"subnet": "10.0.1.0/24",
"pools": [
{ "pool": "10.0.1.100-10.0.1.200" }
],
"option-data": [
{ "name": "routers", "data": "10.0.1.1" }
],
"reservations": [
{
"hw-address": "00:1a:2b:3c:4d:5e",
"ip-address": "10.0.1.50",
"hostname": "printer-lobby"
}
]
}
]
}
}Key differences from dhcpd:
- Configuration is strict JSON. A missing comma or extra trailing comma breaks the parser. Validate with
kea-dhcp4 -t /etc/kea/kea-dhcp4.confbefore restarting. - Each subnet needs a unique numeric
id. - Reservations live inside the subnet block, not at the global level.
lfc-intervalcontrols how often the lease file is compacted (lease file cleanup). Set this to avoid unbounded growth of the CSV lease file.
Kea lease database backends
Kea supports three lease storage backends:
- memfile -- CSV file at
/var/lib/kea/dhcp4.leases. Simple, no dependencies. Fine for small to medium deployments. - MySQL -- stores leases in a MySQL/MariaDB database. Required for high availability with shared lease state.
- PostgreSQL -- same concept, PostgreSQL backend. Choose based on your existing database infrastructure.
To switch to MySQL:
# Install the backend package
sudo apt install kea-admin # includes database schema tools
# Initialize the database schema
kea-admin db-init mysql -u kea -p keapass -n kea_leases
# Update kea-dhcp4.conf lease-database section:
"lease-database": {
"type": "mysql",
"host": "dbserver.corp.lan",
"port": 3306,
"name": "kea_leases",
"user": "kea",
"password": "keapass"
}Kea hooks and high availability
Kea's modular design uses hook libraries for extended functionality. Hooks load as shared libraries in the configuration:
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server1",
"mode": "hot-standby",
"peers": [
{ "name": "server1", "url": "http://10.0.1.5:8000/", "role": "primary" },
{ "name": "server2", "url": "http://10.0.1.6:8000/", "role": "standby" }
]
}]
}
}
]The HA hook provides hot-standby and load-balancing modes, replacing the proprietary failover protocol of ISC dhcpd. It communicates over HTTP between the peers and synchronizes leases automatically.
DHCP Relay Agents for Multi-Subnet Networks
DHCP broadcasts do not cross routers. In multi-subnet networks, you need a DHCP relay agent on each subnet (or on the router itself via ip helper-address on Cisco gear). Proper subnet design is fundamental to relay configuration -- see Linux networking basics with IP, subnet, and routing for the underlying concepts.
# ISC DHCP relay
sudo dhcrelay -i eth1 10.0.1.5
# Kea provides kea-dhcp-ddns for DNS updates, but relay is typically
# handled by the network infrastructure (router-based helper).
# On Linux, isc-dhcp-relay still works as the relay agent.The relay agent listens for broadcasts on the local subnet, wraps them in a unicast packet, and forwards them to the DHCP server. The server uses the relay agent's address (giaddr) to determine which subnet the request came from and assigns an address from the correct pool.
Testing DHCP from a Linux client
When troubleshooting DHCP issues, you can manually trigger the DORA process from a Linux client to verify server behavior:
# Release the current lease and request a new one
sudo dhclient -r eth0 && sudo dhclient eth0
# Verbose mode to see the full DORA exchange
sudo dhclient -v eth0
# On systems using NetworkManager
sudo nmcli connection down eth0 && sudo nmcli connection up eth0
# Inspect the lease file on the client
cat /var/lib/dhcp/dhclient.leasesThe -v flag on dhclient prints each step of the DORA process, making it easy to identify where communication fails. If the client receives an Offer but never gets an Acknowledge, the issue is usually a firewall blocking return traffic on UDP port 68. For firewall troubleshooting, see Linux server security with nftables and firewalld.
PXE Boot Integration with DHCP
DHCP servers can tell PXE clients where to find a boot image. This is how you set up network-based OS installations and diskless workstations.
PXE with ISC dhcpd
# Add to dhcpd.conf subnet or host block
next-server 10.0.1.20; # TFTP server IP
filename "pxelinux.0"; # Legacy BIOS boot
# For UEFI clients:
# filename "grubx64.efi";PXE with Kea DHCP
"option-data": [
{ "name": "boot-file-name", "data": "pxelinux.0" },
{ "name": "tftp-server-name", "data": "10.0.1.20" }
]Modern PXE deployments often distinguish between BIOS and UEFI clients. Kea's client classification system can match on the client architecture option (option 93) to serve different boot files:
"client-classes": [
{
"name": "UEFI-64",
"test": "option[93].hex == 0x0007",
"boot-file-name": "grubx64.efi"
},
{
"name": "Legacy-BIOS",
"test": "option[93].hex == 0x0000",
"boot-file-name": "pxelinux.0"
}
]Kea DDNS: Dynamic DNS Updates from DHCP
Kea can update DNS records when leases are granted, so hostnames resolve automatically. This requires the kea-dhcp-ddns service:
# In kea-dhcp4.conf, enable DDNS forwarding:
"dhcp-ddns": {
"enable-updates": true,
"server-ip": "127.0.0.1",
"server-port": 53001
}
# kea-dhcp-ddns.conf handles the actual DNS update:
{
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [{
"name": "corp.example.com.",
"dns-servers": [{ "ip-address": "10.0.1.10" }]
}]
},
"reverse-ddns": {
"ddns-domains": [{
"name": "1.0.10.in-addr.arpa.",
"dns-servers": [{ "ip-address": "10.0.1.10" }]
}]
}
}
}DHCP Server Configuration Quick Reference
| Task | ISC dhcpd | Kea |
|---|---|---|
| Config file | /etc/dhcp/dhcpd.conf |
/etc/kea/kea-dhcp4.conf |
| Syntax check | dhcpd -t -cf /etc/dhcp/dhcpd.conf |
kea-dhcp4 -t /etc/kea/kea-dhcp4.conf |
| Lease file | /var/lib/dhcp/dhcpd.leases |
/var/lib/kea/dhcp4.leases |
| Service name | isc-dhcp-server / dhcpd |
kea-dhcp4-server |
| HA method | Failover peer (proprietary) | HA hook (hot-standby / load-balance) |
| DDNS | Built-in ddns-update-style | kea-dhcp-ddns service |
| DB init (Kea) | N/A | kea-admin db-init mysql -u user -p pass -n db |
| PXE option | next-server + filename |
tftp-server-name + boot-file-name |
| Relay agent | dhcrelay -i eth1 server_ip |
dhcrelay (same tool) or router helper |
Summary
ISC dhcpd still works and still runs in many production networks, but new deployments should use Kea DHCP. The migration path is straightforward: translate dhcpd.conf declarations into Kea's JSON format, decide on a lease backend (memfile for small sites, MySQL or PostgreSQL for shared HA state), and set up the HA hook for redundancy. Both servers handle PXE boot through the same DHCP options, and both can update DNS dynamically. The biggest operational difference is that Kea validates configuration strictly at startup -- a malformed JSON file stops the service cold -- while dhcpd is more permissive about syntax but can silently misinterpret ambiguous configurations. Always validate before restarting either server, and always keep the lease file or database backed up. Losing the lease database means every client on the network will request a new address simultaneously at next renewal, which can cause address conflicts and brief connectivity outages.
