DHCP on Linux Servers: When to Use It and Why It Surprises

DHCP (Dynamic Host Configuration Protocol) automates IP assignment, and almost every machine on a network uses it at some point. On servers, though, DHCP is a double-edged sword. It makes initial provisioning effortless, but it can silently change your address, hand out the wrong DNS server, or bind to an interface the way you least expect. Understanding what DHCP actually does on Linux explains most of these surprises.

What Happens at Boot

When a Linux interface uses DHCP, the client sends a broadcast DISCOVER message, receives one or more OFFERs, sends a REQUEST for a specific offer, and on approval acquires a lease. The lease has a renewal time, usually half the lease duration. At that point the client sends a unicast RENEW to the server. If the server does not respond, the client retries, and when the lease expires entirely, the address is released.

journalctl -u systemd-networkd -n 50 | grep -i dhcp
dhclient -v eth0
cat /var/lib/dhcp/dhclient.leases

The third command reads the DHCP lease file, which records the address, the subnet mask, the gateway, DNS servers, lease start and expiry times. If your address suddenly changes, this file shows the history and the exact renewal timeline.

Why DHCP Surprises You on a Server

The classic server surprise is an address change after a reboot or a network blip. The DHCP server assigns addresses from a pool on a first-come basis. If your lease expired or the server sees a different client identifier, it may issue a new address. Any service that hardcodes its address, any firewall rule, and any DNS record pointing at the old IP breaks instantly.

A second surprise is DNS. DHCP servers commonly push a DNS server list via option 6. If that option points at an internal resolver you did not expect, your name resolution silently changes. Tools like NetworkManager or systemd-networkd often also drop or rewrite your /etc/resolv.conf after each DHCP renewal.

resolvectl status eth0
cat /run/systemd/resolve/resolv.conf

The PerInterface DNS configuration shows exactly which DNS server DHCP injected for that interface. If you have been fighting DNS inconsistency, this is where the injected nameserver is documented.

When DHCP Makes Sense on Servers

For all its hazards, DHCP can be the right call in specific cases. On a cloud VPS, the provider almost always manages addressing via DHCP because the infrastructure assigns a floating address independent of the guest. On those systems the DHCP lease maps to a stable address, so it behaves like a static IP from your perspective.

DHCP is also correct for provisioning fleets. A deployment tool boots an instance, obtains an address, and applies configuration to it before the job finishes. When your fleet scales and the exact address does not matter because you use DNS or a service mesh for discovery, DHCP is the pragmatic choice.

Configuring DHCP on systemd-networkd

To use DHCP with systemd-networkd, create a .network file with a DHCP line in the [Network] section.

[Match]
Name=eth0

[Network]
DHCP=yes

[DHCPServer]
PoolOffset=100
PoolSize=20

The first part sets eth0 as a DHCP client. The second part nearly turns it into a DHCP server, which serves addresses in a small range. If you run a lab or test environment, this turns a Linux box into a lightweight DHCP server for a virtual network.

DHCP With Netplan

On Ubuntu, Netplan abstracts DHCP configuration. Setting dhcp4 to true enables client mode.

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
        use-routes: true

The dhcp4-overrides block is subtle and powerful. Setting use-dns to false tells NetworkManager or systemd-networkd to ignore the DNS servers provided by DHCP, keeping your own nameservers instead. Setting use-routes true keeps the default route that DHCP provides. These overrides resolve the DNS surprise problem while retaining dynamic addressing.

Making DHCP Predictable

When you must run DHCP in production, take the surprise out of it. Configure a static DHCP reservation on the server side so the same MAC address always receives the same lease. This combines dynamic management with a fixed outcome.

ip link show eth0
cat /sys/class/net/eth0/address

Write down the MAC from the second command and register it in your DHCP server as a static reservation. Now the address is stable even though the protocol is dynamic. This is exactly how cloud providers keep guest addresses deterministic while still using DHCP under the hood.

The Bottom Line

Decide deliberately. If your provider manages addressing (typical for VPS), use their DHCP and treat it as effectively static. If you manage the network yourself, prefer actual static configuration for anything that needs a fixed address, and use DHCP only in ephemeral or auto-provisioning roles.

The safest approach on most production servers is explicit static IPs for anything with a name, with DHCP reserved only for the interfaces that genuinely roam. You can review host networking choices on a Netbay VPS with full console access at netbayhosts.in.