On this page

# Topics

Linux concept: DHCP

25 August 2026

You plug in a network cable, or join a wifi network, and a few seconds later everything works. You did not choose an IP address, look up a gateway, or type in a DNS server. Something handed all of that to your machine while you were still opening the laptop lid. That something is DHCP, and on most networks it is the single most consequential service nobody thinks about until the day it stops.

1. The Basics

DHCP is how a machine that knows nothing about a network gets everything it needs to use that network. It solves a chicken-and-egg problem: to ask a server for configuration you need an address, and the address is exactly what you are asking for.

The trick is broadcast. A machine with no address shouts into the local network, and any DHCP server that hears it answers. That is why DHCP only works on the network segment you are physically attached to, and why a router has to be specially configured to relay it anywhere else. Section 5 covers how that relaying works, since almost no organisation runs a separate server per VLAN.

1.1 It Is Not Just an Address

Most people describe DHCP as "the thing that gives you an IP address". That is the smallest part of what it does. A typical lease also carries the settings that make the address useful:

What arrives	Why you need it	Without it
IP address and prefix	Your identity on this network, and which addresses are local	No networking at all
Default gateway	Where to send anything that is not local	The local network works, the internet does not
DNS servers	Turning names into addresses	Addresses work, names do not: "the internet is down"
Search domain	Completing short names like `printer`	Short internal names stop resolving
NTP servers	Setting the clock	Clock drift, then certificate and authentication failures
Lease time	How long this is all valid for	No way to reclaim addresses

That third row is worth pausing on, because it is the most common real-world DHCP failure. When DHCP hands out a DNS server that is wrong or unreachable, every symptom points at DNS, the internet, or the website. Almost nobody looks at the thing that supplied the DNS server in the first place.

1.2 A Lease Is a Rental, Not a Gift

DHCP does not give you an address. It lends you one, for a stated period, and expects you to come back and ask again before the period ends.

This is the design decision that makes everything else make sense. Addresses are a finite resource on any given network, and devices come and go constantly. A lease means an address returns to the pool automatically when a laptop leaves and never comes back, without anybody maintaining a list.

The right mental model: DHCP is a rental agreement with a clock on it, not a database of who owns what. Every strange DHCP behaviour makes sense once you ask "where is this machine in its lease cycle?"

1.3 What This Article Covers

This article covers what DHCP hands out and why, the four-packet conversation that delivers it, how leases are renewed and what happens when they are not, how to read your own machine's lease, how to run a server, and the security problem sitting at the centre of the protocol.

DHCP and DNS are neighbours and are constantly confused with each other. DHCP is how your machine learns which DNS server to ask; DNS is what happens after that. The companion article on DNS covers the second half.

2. Where the Name Comes From

DHCP stands for Dynamic Host Configuration Protocol, and every word in it was chosen against something specific.

DHCP  =  Dynamic Host Configuration Protocol

Dynamic, because the previous systems were static. Configuration was written down by hand, per machine, and changing a network meant visiting every device.
Host, the old word for any machine attached to a network, from an era when that mostly meant something large in a room with a raised floor.
Configuration, deliberately broader than "address". Even in 1993 the intent was to deliver a whole settings package.
Protocol, because it is a defined conversation, not a product. Any client can talk to any server.

The word doing the most work is dynamic. It is the whole point: a machine that has never been on this network before, and whose administrator has never heard of it, can arrive and be configured correctly in under a second with no human involved.

3. A Short History

DHCP is the third attempt at the same problem, and each attempt failed in a way that shaped the next one.

The first was RARP, Reverse ARP: a machine broadcast its hardware address and asked "who am I?". It worked, and it gave back exactly one thing, an IP address, with no gateway, no DNS, and no way to extend it. It also could not cross a router, because it lived below the IP layer entirely.

BOOTP replaced it in September 1985 with RFC 951, the "Bootstrap Protocol". BOOTP ran over UDP, so it could be relayed across routers, and it could carry extra settings. Its limitation was in the name: it was built for booting diskless workstations from a fixed table. An administrator still wrote down every machine's hardware address by hand, and an address was assigned permanently.

DHCP kept BOOTP's packet format, which is why the two interoperate, and added the missing idea: leases. Addresses could now be handed out from a pool, temporarily, to machines nobody had ever registered. The specification everything still runs on is RFC 2131, published in March 1997 by R. Droms, which replaced the earlier RFC 1541.

Year	Milestone
1984	RARP: broadcast your hardware address, get an IP address back and nothing else
1985	RFC 951 defines BOOTP, which can be relayed and can carry options, but assigns from a hand-written table
1993	The first DHCP specification adds leases and dynamic pools on top of BOOTP's packet format
1997	RFC 2131 supersedes it and is still the specification in use today
2018	RFC 8415 consolidates DHCPv6, replacing seven earlier documents including RFC 3315
2022	ISC declares ISC DHCP end-of-life on 5 October and points new deployments at Kea

Two things follow from that history. The packet still carries BOOTP-era fields with names like next_server and root_path, because DHCP inherited the format rather than replacing it. And the protocol was designed in an era when everything on a local network was assumed to be friendly, which is the root of the security problem in section 9.

4. DORA and the Life of a Lease

Getting a lease is a four-packet conversation, and it has a name that has been keeping people through certification exams for decades: DORA.

4.1 The Four Packets

CLIENT                                          SERVER
  |                                                |
  |  1. DISCOVER   broadcast: "is anyone there?"   |
  |  ──────────────────────────────────────────────>  |
  |                                                |
  |  2. OFFER      "you may have 192.168.1.198"    |
  |  <──────────────────────────────────────────────  |
  |                                                |
  |  3. REQUEST    broadcast: "I accept, from you" |
  |  ──────────────────────────────────────────────>  |
  |                                                |
  |  4. ACK        "confirmed, here is everything" |
  |  <──────────────────────────────────────────────  |

Step	What happens
DISCOVER	The client has no address, so it broadcasts to the whole segment. It includes its hardware address and a list of the options it would like.
OFFER	Every DHCP server that heard it may offer an address. On a healthy network there is one server; on a broken one there are two, and that is the problem in section 9.1.
REQUEST	The client picks one offer and broadcasts its acceptance, naming which server it chose. The broadcast is deliberate: it tells the servers it did not pick to release their offers.
ACK	The chosen server confirms and sends the full settings package. Only now does the client configure the interface.

The detail worth remembering is why REQUEST is broadcast rather than sent directly. It looks wasteful, since the client already knows which server it wants. But if two servers both offered, only a broadcast tells the loser that its offer was declined, so it can put that address back in the pool instead of holding it.

4.2 The Wire, and the Messages DORA Leaves Out

All four packets travel over UDP, on two ports that have not changed since before DHCP existed:

$ grep -E '^(bootps|bootpc|dhcpv6)' /etc/services
bootps          67/udp
bootpc          68/udp
dhcpv6-client   546/udp
dhcpv6-server   547/udp

Port 67 is the server, port 68 is the client. Look at the names, though: they are still bootps and bootpc, for BOOTP server and BOOTP client. Forty years later the ports are registered under the name of the protocol DHCP replaced, which is the same inheritance that left next_server in the packet.

UDP is the right choice here for a reason that is easy to miss: TCP needs a working IP configuration to complete a handshake, and at DISCOVER time the client does not have one. The protocol has to work before the network does.

Because it is plain UDP on known ports, you can watch the whole conversation:

$ sudo tcpdump -ni any 'udp port 67 or udp port 68'

This is the tool of last resort and the one that ends arguments. It shows whether a DISCOVER actually left the machine, whether anything answered, and crucially how many things answered.

DORA is only the happy path. The protocol defines four more messages, and each one names a specific situation:

Message	Direction	Means
`DECLINE`	Client to server	"That address is already in use." The client tested it, usually with ARP, and found somebody there.
`NAK`	Server to client	"Your idea of your address is wrong." Typically because the machine moved to a different subnet and asked to keep its old lease.
`RELEASE`	Client to server	"I am done with this address." Politely returns the lease early, which is why a clean shutdown frees an address and pulling the plug does not.
`INFORM`	Client to server	"I have an address already, just send me the settings." Used by statically configured machines that still want the DNS and NTP servers.

DECLINE is the one worth recognising in a capture. A client declining an address means something else on the network is already using it, and that has a short list of causes: a machine configured statically inside the lease range, a second DHCP server, a stale reservation, or a cloned virtual machine carrying its original address. All four are configuration errors rather than DHCP faults.

4.3 Renewal: The Part That Runs Forever

DORA happens once. After that, the client spends the rest of its life renewing, and the timers are defined as fractions of the lease:

Point	Timer	What the client does
50% of the lease	T1, renewal	Asks the same server directly to extend. Usually succeeds, nobody notices.
87.5%	T2, rebinding	The original server has not answered. Broadcasts, asking any server to take over the lease.
100%	Expiry	Gives up the address, tears down the configuration, and starts DORA from the beginning.

These fractions explain the behaviour that confuses people most: a DHCP server can be down for a long time before anyone notices. Every machine already holds a valid lease, and none of them needs anything until it reaches 50% of its own term. With a 24 hour lease, a server that dies at nine in the morning produces its first casualty around nine at night, and the failures then trickle in one machine at a time rather than all at once.

It also explains why lease length is a real decision. Short leases mean faster reclamation and faster propagation of changed settings, at the cost of more traffic and a smaller outage window. Long leases mean the opposite. An office of fixed desktops can happily use days; a conference wifi network handing out addresses to hundreds of phones an hour needs minutes.

5. When the Server Is Somewhere Else

Section 1 said DHCP works by broadcasting, and broadcasts stay inside their own segment. That is true, and taken literally it would mean every VLAN, every branch office and every floor of a building needs its own DHCP server. Almost no organisation runs it that way, so something is clearly missing from the story.

5.1 The Relay Agent

The missing piece is a DHCP relay agent, and it usually lives on the router that separates the two networks:

  client VLAN 10                          server VLAN 100
       |                                        |
   [ client ] ──broadcast──> [ router ] ──unicast──> [ DHCP server ]
                              relay agent

The relay listens for DHCP broadcasts on the client side, and forwards them as ordinary unicast packets to a server whose address it has been given. Replies come back the same way. The client never knows any of this happened; it broadcast, and it got an answer.

This is what makes central DHCP possible. One server, or one pair, can serve every subnet in a building, with a relay configured on each router interface pointing at it.

5.2 `giaddr`: How the Server Knows Which Pool to Use

Forwarding the packet solves half the problem. The other half is harder: the server now receives a request that arrived by unicast from a router, and it has no idea which network the client is actually on. Without that, it cannot know which range to lease from.

The answer is a single field in the packet, inherited from BOOTP and named for its original purpose. RFC 2131 defines giaddr as the "relay agent IP address, used in booting via a relay agent". The relay writes its own client-facing address into it, and the server reads that field to decide which subnet configuration applies.

So the chain is short and worth remembering, because it is where central DHCP breaks:

The relay stamps giaddr with the address of the interface the broadcast arrived on.
The server matches giaddr against its configured subnets and picks that pool.
If no subnet matches, the server does not guess. It stays silent, and the client eventually falls back to a 169.254 address.

That last point produces one of the more baffling failures in DHCP: the server is running, the relay is forwarding, packets are arriving, and clients on one particular VLAN get nothing at all. Nothing is broken, the server simply has no pool defined for the network that giaddr names. When a new VLAN has no DHCP, the two things to check are whether a relay is configured on that interface and whether the server has a subnet for it.

5.3 Option 82, and Knowing Which Socket Somebody Plugged Into

Larger networks want more than the subnet. A switch or relay can attach Option 82, the relay agent information option defined in RFC 3046 in January 2001, describing where in the physical network the request entered: which switch, which port, which circuit.

With that, a server can assign addresses by physical location, an internet provider can identify a subscriber line, and the network can refuse a request that arrives from somewhere it should not have. It is mostly an enterprise and ISP concern, and worth recognising if you ever read a lease log full of circuit identifiers rather than hardware addresses.

6. Reading Your Own Lease on Linux

Everything above is visible on the machine in front of you, and looking at a real lease is the fastest way to make the protocol concrete.

6.1 Which Client Do You Actually Run?

Linux has several DHCP clients and you usually did not choose yours. It came with the way your machine manages networks:

Manager	Typical on	Ask it with
NetworkManager	Desktops and laptops	`nmcli device show`
`systemd-networkd`	Servers, containers, cloud images	`networkctl status`
`dhcpcd`	Alpine, Raspberry Pi OS, minimal systems	`dhcpcd -U`
`dhclient`	Older systems; part of the ISC suite	`/var/lib/dhcp/*.leases`

Find out which one is in charge before you go looking for lease files, because most of the guides you will find online assume dhclient and a file that your system may not have.

$ systemctl is-active NetworkManager systemd-networkd dhcpcd
active
inactive
inactive

6.2 The Lease, in Full

On a NetworkManager system, this prints exactly what the server handed over:

$ nmcli -f DHCP4 device show wlp0s20f3
DHCP4.OPTION[1]:    dhcp_client_identifier = 01:2c:6d:c1:13:67:3a
DHCP4.OPTION[2]:    dhcp_lease_time = 1800
DHCP4.OPTION[3]:    dhcp_server_identifier = 192.168.1.1
DHCP4.OPTION[4]:    domain_name_servers = 192.168.1.1
DHCP4.OPTION[5]:    expiry = 1787411669
DHCP4.OPTION[6]:    ip_address = 192.168.1.198
DHCP4.OPTION[7]:    next_server = 192.168.1.1
DHCP4.OPTION[8]:    ntp_servers = 10.12.0.20
DHCP4.OPTION[9]:    requested_broadcast_address = 1
DHCP4.OPTION[10]:   requested_domain_name = 1
DHCP4.OPTION[11]:   requested_domain_name_servers = 1
DHCP4.OPTION[12]:   requested_domain_search = 1
DHCP4.OPTION[13]:   requested_host_name = 1
DHCP4.OPTION[14]:   requested_interface_mtu = 1
DHCP4.OPTION[15]:   requested_ms_classless_static_routes = 1
DHCP4.OPTION[19]:   requested_rfc3442_classless_static_routes = 1

There is more in that output than it first appears, and it is worth reading in two halves.

The entries beginning requested_ are what the client asked for. That list travels in the DISCOVER packet as the parameter request list, and it is the client saying "if you happen to know any of these, please include them". Everything else is what the server actually sent back.

Compare the two halves and the asymmetry is obvious. This client asked for a domain name, a search domain, an MTU, and classless static routes. It received none of them. It did receive an NTP server it never asked for. Neither side is misbehaving: the client asks for everything it can use, the server sends what it has been configured with, and the overlap is whatever it is.

The other fields tell a story too:

dhcp_lease_time = 1800 is thirty minutes, which is short. This router has decided to recycle addresses aggressively, so renewal happens every fifteen minutes.
dhcp_server_identifier and domain_name_servers are the same address. The router is the DHCP server and the DNS resolver, which is normal on a small network and means one device failing takes out both.
expiry is a Unix timestamp. Decode it to know exactly when this lease dies:
```
$ date -d @1787411669
Sat Aug 22 05:14:29 PM CEST 2026
```
next_server is a BOOTP inheritance, the address a machine would boot from over the network. Nothing here uses it.

6.3 Telling Dynamic From Static at a Glance

You do not always need the lease. The kernel records where a route came from, and ip route shows it:

$ ip route
default via 192.168.88.1 dev eth0 proto static metric 100
default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.198 metric 600

Two default routes on one machine, from two different sources. The wired interface was configured by hand, so its route is proto static. The wifi interface got its route from a lease, so it is proto dhcp. The addresses agree:

$ ip -4 addr show wlp0s20f3
    inet 192.168.1.198/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3

That word dynamic is the same statement from the address side: this address has a lease behind it and a clock running on it. A statically configured interface does not carry it.

This is the quickest first check in any "the network is being strange" investigation. If you expected an interface to be static and ip route says proto dhcp, you have found the problem before opening a single configuration file.

7. Running a DHCP Server

Most small networks never run one deliberately: the router does it, and the only configuration is a range in a web interface. The moment you outgrow that, you have a choice to make, and one of the options is a trap.

7.1 Choosing the Software

Software	Good for	Watch out for
`dnsmasq`	Small networks, labs, home routers. DHCP and DNS in one small process, and hostnames it leases become resolvable automatically.	Not built for large or high-availability deployments
Kea	Anything serious and current. ISC's replacement for their own older server, with a database backend, an API, and real high availability.	Different configuration format; expect to learn it rather than port your old file
`isc-dhcp-server`	Nothing new.	End of life since 5 October 2022. Still packaged, still installs, no longer maintained upstream
`udhcpd`	Embedded systems, rescue images, anywhere BusyBox already is	Minimal by design

That third row deserves emphasis, because the packaging hides it. On a current Ubuntu the version you would install is exactly the last one ISC ever published:

$ apt-cache policy isc-dhcp-server kea-dhcp4-server
isc-dhcp-server:
  Candidate: 4.4.3-P1-4ubuntu2
kea-dhcp4-server:
  Candidate: 2.4.1-3ubuntu0.2

Version 4.4.3-P1 is not a coincidence: it is the final maintenance release, published on the day ISC announced the software was finished. Distributions still ship it because a great deal of infrastructure still runs it, and it still works. But it will not get fixes, so it is not something to build on now. For a new deployment the answer is dnsmasq if the network is small, and Kea if it is not.

7.2 The Decisions That Matter

Whatever you run, the same four choices define the result.

The range. Which addresses may be handed out. The mistake here is making it the whole subnet, leaving nothing for the servers, printers and switches that need fixed addresses. Reserve a block at one end and never lease it.

The lease time. Covered in section 4.3. Match it to how fast devices come and go, not to a number you saw in a tutorial.

Reservations. Tying a specific hardware address to a specific IP, so a machine gets a predictable address without being configured statically. This is usually better than static configuration on the device, because the setting lives in one place you control rather than on a machine you may not be able to log into. A printer with a reservation can be moved, replaced, or reset to factory defaults and still come back on the same address.

The options. Gateway, DNS, search domain, NTP. These are the settings that will be wrong on every machine at once if you get them wrong here, which is the real reason to think carefully before changing them.

7.3 One Network, One Server

The protocol has no way to arbitrate between two servers offering addresses on the same segment. Whichever answers first wins, per client, per lease. Two servers with overlapping ranges will therefore hand the same address to two machines eventually, and the resulting fault is intermittent, moves around, and looks like anything but DHCP.

If you need redundancy, do not run two independent servers. Either use a pair that knows about each other, which is what Kea's high availability mode is for, or split the range so the two servers cannot collide.

8. The Options: What Else Arrives With Your Address

The settings DHCP carries are numbered, and a handful of those numbers explain behaviour you have probably already run into.

Option	Carries	Why it matters
1	Subnet mask	Which addresses are local
3	Router (default gateway)	Everything non-local
6	DNS servers	The handoff to DNS
15 / 119	Domain name / search list	Short internal names
42	NTP servers	The clock
51 / 58 / 59	Lease time, T1, T2	The renewal cycle
53	Message type	Which of DORA this packet is
55	Parameter request list	The `requested_` entries in section 6.2
121	Classless static routes	Routes beyond the default gateway

8.1 Option 6: Where Your DNS Comes From

This is the connection people miss most often. Your machine did not choose its DNS server, and neither did you. It arrived in the lease, and on a Linux system it travels from the DHCP client into the resolver configuration automatically:

$ nmcli -f DHCP4 device show wlp0s20f3 | grep domain_name_servers
DHCP4.OPTION[4]:    domain_name_servers = 192.168.1.1

$ resolvectl status | grep -A1 'Current DNS Server'
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

The same address in both places, because the second was set by the first. This is why the DNS article says /etc/resolv.conf is generated rather than edited: a DHCP client is one of the things generating it, and it will overwrite your edits at the next renewal. If you want different DNS servers, change them at the DHCP server, or tell your network manager to ignore the ones the lease supplies.

8.2 Option 121: The One That Silently Does Nothing

Option 3 gives a client one default gateway. Option 121 gives it a full routing table, which is how a network hands out "for the 10.20.0.0/16 range, go via this other router" without configuring anything on the client.

The catch is that support is not universal, and a client that does not understand option 121 does not report an error. It simply ignores the routes and uses the default gateway for everything. The symptom is that one particular subnet is unreachable from some machines and fine from others, with no error message anywhere. If you push routes by DHCP, verify on each operating system that they actually arrived.

8.3 Option 42 and the Clock

The lease in section 6.2 included ntp_servers = 10.12.0.20, which the client never requested and received anyway. Time is worth having: a machine with a badly wrong clock cannot validate a TLS certificate, cannot authenticate against Kerberos, and produces logs that cannot be correlated with anything.

Whether that option is used depends on the time daemon, and several ignore DHCP-supplied servers in favour of their own configured pool. As with option 121, the failure is silent, so check rather than assume.

9. Something Most Users Do Not Know

9.1 DHCP Has No Authentication At All

This is the uncomfortable fact at the centre of the protocol. A client broadcasts a request and configures itself from whatever answers first. It cannot tell a legitimate server from any other machine on the segment, because there is no mechanism to tell them apart. None was designed, because in 1993 the local network was assumed to be trustworthy.

The consequence is that anyone who can plug into your network can become its DHCP server. And they do not need to break anything to do damage, because the useful attack is not handing out bad addresses. It is handing out a good address with a bad gateway, so every packet leaving every affected machine routes through theirs first.

The everyday version is not malicious at all. Somebody plugs a home router into an office wall socket the wrong way round, its DHCP server starts answering, and a random subset of machines take leases from it. The symptoms are memorable: some machines work, some do not, the broken ones share a strange address range, and everything looks fine on the machines you happen to check first.

The defences are all outside DHCP itself, because the protocol has nothing to offer:

DHCP snooping on managed switches, which drops DHCP server replies arriving on ports that are not supposed to have a server behind them. This is the real fix and it is a switch feature, not a server setting.
Port security and network segmentation, so an untrusted socket cannot reach the segment your machines are on.
Monitoring: know which server is meant to answer, and check the dhcp_server_identifier in a lease when something is strange. It is one command, and it names the culprit immediately.

9.2 Starving the Pool Instead of Poisoning It

The mirror image of a rogue server is DHCP starvation, and it exploits the same missing authentication from the other direction. Instead of answering requests, the attacker makes them: thousands of leases claimed under invented hardware addresses until the pool is empty.

Nothing then works for anyone new. Machines already holding a lease carry on, so the network appears healthy to everybody sitting at a desk, while every arriving laptop and every rebooting machine gets nothing. The symptom looks like the DHCP server having failed, and the server is fine: it is doing exactly what it was asked, several thousand times.

Starvation is also the setup for the previous section. Empty the real pool first, then answer the requests it can no longer serve, and clients take the attacker's configuration without anything appearing unusual.

The defences are the same switch-level controls, plus one thing you can check yourself: a pool that is suspiciously full of leases to hardware addresses nobody recognises is the signature, and it is visible in the server's own lease list.

9.3 The 169.254 Address Means DHCP Failed

When a machine finds no DHCP server, it does not usually give up with nothing. It assigns itself an address from 169.254.0.0/16, the link-local range, picked at random and checked for collisions.

$ ip -4 addr | grep 169.254

Two machines that both do this can talk to each other, and nothing else works: no gateway, no DNS, no internet. On Windows the same mechanism is called APIPA, and the symptom is the famous "self-assigned IP address" that means the same thing.

So a 169.254 address is not a configuration to debug. It is a message, and the message is "no DHCP server answered me". Look at the cable, the switch port, the VLAN, and the server, in that order.

9.4 IPv6 Mostly Does Not Use DHCP

Everything so far has been IPv4. IPv6 solved the same problem differently, and the difference surprises people who go looking for DHCPv6 and cannot find it running.

IPv6 has SLAAC, stateless address autoconfiguration. A router periodically announces the network prefix, and each machine builds its own address from that prefix without asking permission or holding a lease. There is no server keeping records, because there is nothing to keep.

$ ip -6 addr show wlp0s20f3
    inet6 fe80::6e5a:efe7:e2b6:1a81/64 scope link noprefixroute

That fe80:: address is IPv6's own link-local, the equivalent of 169.254, and every IPv6 interface has one always. Here there is no global address alongside it, which means this network is not announcing an IPv6 prefix at all.

DHCPv6 exists, consolidated into RFC 8415 in November 2018, and is used when you need what SLAAC cannot do: recorded assignments, options like DNS servers on networks where the router advertisement does not carry them, and prefix delegation to downstream routers. Many networks run both, which is why an IPv6 machine can have several addresses at once from different mechanisms.

9.5 Your Hostname May Not Be Yours

The lease conversation can carry a hostname in either direction. A client can tell the server what it calls itself, and a server can tell a client what it should call itself.

Combined with dynamic DNS, this is how a machine that arrives on a network becomes resolvable by name without anybody creating a record: the DHCP server registers the name it just leased into DNS. dnsmasq does this by default for the names it hands out, which is a large part of why it is popular on small networks.

It is also a quiet source of confusion. A machine's name in DNS may be one the DHCP server chose, not the one in /etc/hostname, and the two can disagree indefinitely without anything appearing to be wrong.

9.6 Knowing Where DHCP Stops

DHCP configures an interface. That is the whole job, and it ends the moment the interface is configured.

Symptom	Is it DHCP?	Where to look
No address, or a `169.254` one	Yes	Cable, switch port, VLAN, then the server
Address fine, no internet	Often	The gateway in the lease, and option 121 routes
Address fine, names do not resolve	Sometimes	Option 6, then the resolver itself
Works, then breaks at the same interval	Yes	Renewal at 50% of the lease; the server is not answering
Wrong address range on some machines	Yes	A second DHCP server on the segment
Site loads slowly	No	The application or the path; DHCP ran once, minutes ago

The fourth row is the signature worth memorising. Anything that fails on a regular cycle, especially one that is half of a round number of minutes or hours, is a renewal problem, and no amount of investigating the application will find it.

10. Best Practices

Run one DHCP server per network segment. The protocol cannot arbitrate between two, so two servers with overlapping ranges will eventually hand the same address to two machines. If you need redundancy, use a pair that knows about each other or split the range.
Reserve part of the subnet and never lease it. Servers, printers, switches and access points need addresses that do not move. Decide the boundary once and write it down.
Prefer reservations over static configuration on the device. The setting lives in one place you control, and the device can be replaced or factory reset and still come back correctly.
Match the lease time to how fast devices come and go. Days for fixed desktops, minutes for guest wifi. Remember that the renewal cycle starts at 50%, so a short lease also shortens how long a dead server stays invisible.
Lower the lease time before changing DHCP options, not while changing them. Every machine keeps its current settings until it renews, so a shorter lease a day ahead means the whole network picks up the new gateway or DNS server in minutes rather than over a day.
Turn on DHCP snooping on managed switches. It is the only real defence against a rogue server, and the protocol offers nothing itself.
Know which server is supposed to answer. When something is strange, read dhcp_server_identifier from a client's lease. If it names something unexpected, you have found the problem in one command.
Do not fix DHCP-supplied DNS by editing /etc/resolv.conf. The next renewal overwrites it. Change it at the DHCP server, or configure the client to ignore that option.
Verify pushed routes and NTP servers actually arrived. Options 121 and 42 fail silently on clients that ignore them, and the symptom is one unreachable subnet or a drifting clock, not an error.
Treat a 169.254 address as a diagnosis, not a fault to configure around. It means no server answered.
Do not build anything new on ISC DHCP. It has been end-of-life since October 2022. Use dnsmasq for small networks and Kea for everything else.

11. Common Mistakes

11.1 Myth versus Reality

Myth	Reality
"DHCP gives out IP addresses."	It gives out a configuration package. The gateway, DNS servers, search domain and NTP servers matter just as much, and are likelier to be the thing that is wrong.
"My machine owns its address."	It rents it. The lease has a clock on it and renewal starts at the halfway point.
"The DHCP server is down, so the network is down."	Not immediately. Every machine keeps working until it reaches 50% of its own lease, so failures start hours later and arrive one machine at a time.
"A `169.254` address is a misconfiguration."	It is the client reporting that no DHCP server answered at all.
"DHCP is secure because it is on my local network."	DHCP has no authentication of any kind. Whoever answers first wins, which is why DHCP snooping on the switch exists.
"I set my DNS server in `/etc/resolv.conf`."	The DHCP client rewrites that file at the next renewal. The setting has to change at the server or be explicitly ignored by the client.
"IPv6 uses DHCP the same way."	IPv6 mostly uses SLAAC, where machines build their own addresses from a router advertisement and no server keeps records.
"A reservation is the same as a static IP."	The result looks the same, but a reservation lives on the server, so the device can be reset or replaced without anybody reconfiguring it.
"`isc-dhcp-server` is the standard, it is in the repository."	It is packaged and end-of-life. The version distributions ship is the last one ISC published before stopping.

11.2 Other Traps to Avoid

A lease range that covers the whole subnet. Sooner or later DHCP hands out the address your file server has been using statically, and both machines break in ways that look unrelated.
Changing an option and expecting it to take effect now. Machines pick up new settings when they renew, not when you save the file. Half your network may be running on the old gateway for hours.
Static addresses inside the lease range. The server does not know they exist and will lease them to somebody else. If you must, configure them as reservations instead.
Assuming the router is the only DHCP server. Anything can be one: a spare access point in bridge mode, a virtualisation host, a colleague's development VM with a bridged interface.
Debugging DNS when DHCP handed out the wrong resolver. Check where the resolver address came from before investigating the resolver itself.
Very long leases on a network with churn. A guest network with a week-long lease runs out of addresses, and the failure looks like the wifi being broken.
Forgetting the relay when you add a VLAN. DHCP is broadcast, so it does not cross a router. A new segment with no relay configured has no DHCP at all, and every machine on it lands on 169.254.
Blaming DHCP when a host firewall is eating it. The client has no address yet and the traffic is broadcast UDP on ports 67 and 68, which is exactly the shape of packet a restrictive ruleset drops. Capture first with tcpdump to find where the packets stop, then look at nft list ruleset. Do not start by changing firewall rules.
Trusting one machine's view. With two servers on a segment, whichever answers first wins per client, so machine A can be perfectly healthy while machine B next to it is not.

12. Summary

DHCP is the service that configures everything and gets credited with nothing. It runs once when a machine arrives, quietly renews for as long as it stays, and is invisible until the day it is not.

DHCP solves a chicken-and-egg problem by broadcasting: a machine with no address shouts, and whoever hears it answers. That is why it does not cross routers without a relay.
It hands out far more than an address: gateway, DNS servers, search domain, NTP servers and the lease time. The DNS entry is the one that causes the most misdiagnosed outages.
An address is a lease, not a possession. It has a clock on it and it returns to the pool by itself.
DHCP is the third attempt: RARP gave only an address, BOOTP (RFC 951, 1985) added relaying and options but used a hand-written table, and DHCP added pools and leases. RFC 2131 from March 1997 is still the specification.
DORA is the four-packet exchange: Discover, Offer, Request, Acknowledge. REQUEST is broadcast on purpose, so servers whose offers were declined can release them.
Renewal starts at 50% of the lease and rebinding at 87.5%. This is why a dead DHCP server produces no symptoms for hours and then failures trickle in one machine at a time.
It all runs over UDP on ports 67 (server) and 68 (client), still registered as bootps and bootpc. Watch the whole exchange with tcpdump -ni any 'udp port 67 or udp port 68'.
DORA is the happy path. DECLINE means the address is already in use, NAK means the client asked for an address that is wrong for this subnet, RELEASE returns a lease early, and INFORM asks for settings without an address.
Broadcasts do not cross routers, so a relay agent forwards them and stamps its own address into giaddr. The server picks the pool from that field, which is why a VLAN with no matching subnet gets silence rather than an error.
Read your own lease with nmcli -f DHCP4 device show, or networkctl status under systemd-networkd. The requested_ entries are what the client asked for; everything else is what the server actually sent.
ip route labels every route with its origin. proto dhcp versus proto static answers "is this interface configured by hand?" in one command.
Run one server per segment, reserve part of the subnet, and prefer reservations to configuring addresses on devices.
ISC DHCP has been end-of-life since October 2022. Use dnsmasq for small networks, Kea for larger ones.
DHCP has no authentication. Whoever answers first wins, so a rogue server is trivially easy and DHCP snooping on the switch is the only real defence.
A 169.254 address means no server answered. It is a diagnosis, not a setting.
IPv6 mostly uses SLAAC instead: machines build addresses from a router advertisement, with no server and no lease. DHCPv6 (RFC 8415) exists for what SLAAC cannot do.
DHCP is where your machine learns which DNS server to ask. What happens next is in the companion article on DNS.

This is the checklist worth keeping when a network behaves strangely:

DID DHCP WORK AT ALL
  ip -4 addr                     an address, or 169.254 (nothing answered)
  ip route                       proto dhcp or proto static?

WHAT DID IT ACTUALLY SAY
  nmcli -f DHCP4 device show IF  the whole lease, both halves
  networkctl status IF           the same under systemd-networkd
  dhcp_server_identifier         WHICH server answered: check this first
  dhcp_lease_time                renewal happens at half of it
  date -d @<expiry>          when this lease dies

WHERE DID THE SETTINGS GO
  resolvectl status              DNS servers, should match option 6
  ip route                       gateway, plus any option 121 routes

IF NOTHING ANSWERS AT ALL
  tcpdump -ni any 'udp port 67 or udp port 68'
                                 did the DISCOVER leave? did anything reply?
  relay configured on this VLAN?  broadcasts do not cross routers
  server has a subnet for giaddr? no match means silence, not an error
  host firewall                  broadcast UDP 67/68 is easy to drop

WHEN IT IS INTERMITTENT
  same interval every time       renewal failing at 50% of the lease
  only some machines             a second DHCP server on the segment
  one subnet unreachable         option 121 routes ignored by that client

A network where machines appear, configure themselves correctly and keep working is not luck: it is one server answering on each segment, a range that does not collide with anything fixed, a lease time that matches how the network is used, and a switch that refuses to let anything else answer.

If a network has grown into intermittent faults that move between machines, or nobody is quite sure which device is handing out addresses any more, that is worth an afternoon of somebody's attention before it becomes the morning everybody arrives and nothing works.