5.4.4 DHCP server configuration

Introduction

Dynamic Host Configuration Protocol, or DHCP, is the standard way most networks automatically assign IP addresses and related network settings to clients. On a Linux server, running a DHCP service means taking responsibility for handing out addresses, tracking leases, and sometimes providing additional information such as DNS servers and default gateways. This chapter focuses on configuring a DHCP server on Linux in a practical way, without re-explaining general DNS concepts or broader networking theory covered elsewhere.

Core DHCP Concepts for Configuration

A DHCP server maintains a pool of IP addresses and configuration parameters and allocates them dynamically to clients. When you configure a DHCP server, you primarily define three kinds of information.

First, you define the network or networks the server will serve. This includes the subnet address, the netmask, and the range of addresses that can be assigned dynamically to clients. Second, you define general options that apply to clients, such as the default gateway, DNS servers, lease times, and domain name. Third, you define special rules such as static leases that always assign the same IP to a specific client based on its MAC address.

Most Linux DHCP deployments use ISC DHCP (isc-dhcp-server) or Kea DHCP from ISC, or dnsmasq in smaller or embedded setups. The configuration ideas are similar across implementations. This chapter will use ISC DHCP (dhcpd) as the main reference, and then briefly mention the differences in Kea and dnsmasq.

Installing a DHCP Server

On Debian and Ubuntu based systems, the classic ISC DHCP server package is isc-dhcp-server. On Fedora, RHEL, and derivatives, the package is usually dhcp-server. Installation is done through the distribution package manager and is usually straightforward. The service is typically installed with a default configuration file and a systemd unit, but the service will not function until you define at least one valid subnet and range.

Kea DHCP is a newer ISC product with a different configuration style, using JSON files and a separate control agent. You install Kea using packages such as kea-dhcp4-server or similar names, and it runs as a separate daemon for IPv4 and IPv6. Dnsmasq is often installed as dnsmasq and can serve both DNS and DHCP for small networks.

This chapter concentrates on the structure and logic of the configuration, which is more important than the exact package name, since that can vary slightly between distributions.

Basic ISC DHCP Configuration Structure

The main configuration file for ISC DHCP is usually /etc/dhcp/dhcpd.conf. There is also a lease database file, usually /var/lib/dhcp/dhcpd.leases, which the daemon maintains automatically. The configuration file is made up of server wide directives, shared network and subnet definitions, and per host sections.

At the top level, you typically define global options such as default and maximum lease times, whether the server is authoritative for the network, and default options like DNS servers and domain names. Below that, you define one or more subnet blocks, which define the address pool for a specific network, together with more specific options and ranges. Option values defined inside a subnet override global values for that subnet.

A very small but complete DHCP configuration for a single IPv4 network might look like this.

default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
    option domain-name-servers 192.168.10.1, 1.1.1.1;
    option domain-name "example.local";
}

This example shows the basic building blocks that all configurations share.

Defining Subnets and Address Pools

Subnets are the core of the DHCP configuration. Each subnet statement declares the network address and netmask, and within it you define at least one range for dynamic allocation. The network address is the base address of the subnet, and the mask instructs the server which addresses belong to that network.

For example, to serve two separate networks, one for offices and one for lab equipment, on different interfaces, you might define two subnet blocks.

subnet 10.0.0.0 netmask 255.255.255.0 {
    range 10.0.0.100 10.0.0.200;
    option routers 10.0.0.1;
    option domain-name-servers 10.0.0.5;
}
subnet 10.0.1.0 netmask 255.255.255.0 {
    range 10.0.1.50 10.0.1.150;
    option routers 10.0.1.1;
    option domain-name-servers 10.0.1.5;
}

Each range defines the first and last address the server can assign automatically. Addresses outside the range but still inside the subnet can be used for static hosts, routers, or infrastructure devices.

You can also define multiple pools inside a single subnet to control how addresses are used. For instance, you can group ranges into pool blocks with additional constraints, such as different lease policies for specific client classes. A pool might look like this.

subnet 10.0.2.0 netmask 255.255.255.0 {
    option routers 10.0.2.1;
    option domain-name-servers 10.0.2.5;
    pool {
        range 10.0.2.50 10.0.2.100;
        allow unknown-clients;
    }
    pool {
        range 10.0.2.150 10.0.2.200;
        deny unknown-clients;
    }
}

In this example, unknown clients get addresses from the first pool, while known or statically defined clients can use addresses from the second pool. Pool based configuration is useful when you want to separate temporary or guest devices from trusted infrastructure.

Lease Times and Authoritative Mode

Lease times control how long a client can use an assigned IP before it must renew. The DHCP server uses default-lease-time and max-lease-time to define these values in seconds. Clients may request specific lease times, but the server can enforce upper limits.

For example, a network where devices rarely change might use a long lease time.

default-lease-time 86400;   # 1 day
max-lease-time 604800;      # 7 days

In a guest Wi Fi environment with many transient clients, shorter leases free addresses more quickly.

default-lease-time 3600;    # 1 hour
max-lease-time 7200;        # 2 hours

The authoritative directive tells clients that this DHCP server is the primary server for this network. In practice, this means the server can quickly correct clients that have stale leases from another network. You should only set authoritative on a server that is actually responsible for the network, because it will send negative acknowledgments to clients that try to use wrong addresses.

Configuring Common DHCP Options

DHCP options specify network parameters other than the IP address itself. The most frequently used options include the default gateway, DNS servers, domain name, NTP servers, and sometimes specific configuration for VoIP phones or PXE boot.

The most common option for the default gateway is option routers. For example.

option routers 192.168.1.1;

DNS servers are configured with option domain-name-servers followed by one or more IP addresses separated by commas.

option domain-name-servers 192.168.1.10, 8.8.8.8;

The domain name clients should use for DNS lookups can be set with option domain-name.

option domain-name "corp.example.com";

If you want to provide NTP servers to clients so they can synchronize time, use option ntp-servers.

option ntp-servers 192.168.1.20;

Many specialized devices use vendor specific options for configuration. ISC DHCP supports these using option declarations that map numbers to named options. For example, DHCP option 66 and 67 are often used for PXE boot configuration for network installs, where 66 indicates the TFTP server name and 67 the boot file.

next-server 192.168.1.30;
filename "pxelinux.0";

These special PXE directives are common in environments where you deploy systems over the network.

Static Leases and Reservations

Static leases, sometimes called reservations, ensure that a specific client always receives the same IP address, based on its hardware (MAC) address. This is helpful for servers, printers, or other devices that need stable addresses but should still be managed through DHCP rather than manual static configuration on the device.

In ISC DHCP, a static lease is defined with a host block.

host printer1 {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 192.168.10.20;
    option host-name "printer1";
}

The hardware ethernet line specifies the client's MAC address, and fixed-address assigns the IP address. You can put host entries inside the relevant subnet block, or at the top level if you are careful about which subnet the address belongs to. The daemon uses the address value to determine which subnet the host belongs to.

You can combine static leases with exclusion from the dynamic range. For example, if your dynamic pool is 192.168.10.100 to 192.168.10.200, you can use the lower part of the network for static leases, such as 192.168.10.10 to 192.168.10.50. This keeps the configuration predictable and avoids conflicts.

Binding DHCP to Network Interfaces

On multi homed servers, you must ensure that the DHCP server listens on the correct network interfaces. Different distributions use different mechanisms for this.

On Debian and Ubuntu, the interfaces are configured in /etc/default/isc-dhcp-server using the INTERFACESv4 and INTERFACESv6 variables. For example.

INTERFACESv4="eth1"
INTERFACESv6=""

On RHEL and Fedora based systems, you typically configure listening interfaces with the DHCPDARGS variable in /etc/sysconfig/dhcpd, for example.

DHCPDARGS="eth1";

Alternatively, some setups rely on additional command line arguments in the systemd unit file. In such a case, you might override the systemd service with a drop in configuration and add interface parameters like dhcpd -4 -q eth1.

The important principle is that the DHCP server must only listen on interfaces that are actually connected to the networks it serves. If it listens on a trunk, management, or uplink interface where it should not hand out addresses, it can disrupt other networks.

Systemd Integration and Service Management

On modern Linux systems, DHCP daemons run as systemd services. Once the configuration file is present and valid, you control the service with systemctl. You enable the service so that it starts at boot, and you start or restart it to apply changes.

Typical operations look like this.

sudo systemctl enable isc-dhcp-server
sudo systemctl start isc-dhcp-server
sudo systemctl restart isc-dhcp-server
sudo systemctl status isc-dhcp-server

On RHEL or Fedora, the service name might be dhcpd instead of isc-dhcp-server. When troubleshooting startup problems, check the status output and then examine the journal logs for the service, for example with journalctl -u isc-dhcp-server or journalctl -u dhcpd.

Most daemons support a configuration test mode. For ISC DHCP, dhcpd -t checks configuration syntax without starting the service. It is a helpful step before restarting a production server.

DHCP Relay and Serving Remote Networks

A DHCP server usually serves clients on the same layer 2 segment. If your clients are on different VLANs or routed networks but you want to use a central DHCP server, you must configure DHCP relay agents on the routers or a dedicated relay host. The relay forwards broadcast based DHCP messages from clients as unicast packets to the DHCP server, which then replies through the relay.

From the DHCP server point of view, this is mostly transparent. The server configuration must include subnet blocks for all the networks it serves, including those behind relays, but the server does not need to have IP addresses in those networks. The relay passes along enough information for the server to identify which subnet is in use, usually through the giaddr field.

For example, you can have a DHCP server on 10.0.0.10 and clients in 10.1.0.0/24 and 10.2.0.0/24 networks, each VLAN having a relay pointing to 10.0.0.10. The server configuration must have subnet 10.1.0.0 and subnet 10.2.0.0 definitions with appropriate ranges. The routers or relay devices handle the forwarding, which is outside the scope of this chapter.

The key configuration point on the server is awareness of all networks for which it will issue leases. Without a matching subnet declaration, the server will not hand out addresses for that network.

Using Kea DHCP: JSON Based Configuration

Kea DHCP uses JSON configuration files and separate daemons for IPv4 and IPv6. The main IPv4 daemon is often called kea-dhcp4, and its configuration file can be something like /etc/kea/kea-dhcp4.conf. In Kea, a typical configuration has a subnet4 list that defines subnets, pools, and options.

A simple Kea IPv4 configuration snippet might look like this.

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth1" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "subnet4": [
      {
        "subnet": "192.168.50.0/24",
        "pools": [
          { "pool": "192.168.50.100 - 192.168.50.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.50.1" },
          { "name": "domain-name-servers", "data": "192.168.50.1,8.8.8.8" },
          { "name": "domain-name", "data": "lab.example.com" }
        ]
      }
    ]
  }
}

Static reservations are defined in a reservations list inside a subnet, using the hw-address and ip-address fields. Kea also provides an HTTP based control interface and can use databases such as MySQL or PostgreSQL as backends, which makes it suitable for larger and more dynamic environments.

Although the syntax is different, the conceptual elements are the same as in ISC DHCP: subnets, pools, options, and reservations.

Using dnsmasq for Small DHCP Deployments

Dnsmasq is a lightweight DNS forwarder and DHCP server commonly used for small networks, home labs, and embedded devices. It uses a relatively simple configuration format, usually in /etc/dnsmasq.conf, and often runs a combined DNS and DHCP service on the same host.

In dnsmasq, enabling DHCP is done with dhcp-range and related directives. For example.