DHCP Server
The service that automatically hands out IP addresses and network config to devices when they join a network — so you don't configure every device by hand. Invisible until it breaks.
What is a DHCP server?
A DHCP (Dynamic Host Configuration Protocol) server automatically assigns IP addresses and related network configuration to devices when they join a network. Plug in a laptop, connect a phone to Wi-Fi, boot a VM — and without anyone typing in numbers, it gets an IP address, a subnet mask, a default gateway, and DNS server addresses. The DHCP server is what hands all of that out. Before DHCP, every device’s network settings had to be configured manually, which was tedious and error-prone at any scale; DHCP automates it, which is why it runs silently in every home router, office network, and cloud VPC.
How it works — the DORA handshake
DHCP assignment follows a four-step exchange, memorably abbreviated DORA: Discover (the new device broadcasts “is there a DHCP server out there?”), Offer (a DHCP server responds “yes, here’s an IP address you can use”), Request (the device replies “I’ll take that one”), and Acknowledge (the server confirms and finalizes the lease). The assigned address comes with a lease — a time limit after which the device must renew — which lets the server reclaim addresses from devices that have left, keeping a limited pool of addresses usable by a rotating set of devices. Servers assign from a configured scope (a range of available addresses) and can make reservations that always give a specific device (identified by its MAC address) the same IP — useful for printers, servers, or anything you want at a predictable address. Beyond the IP itself, DHCP delivers the rest of the config a device needs to actually use the network: the gateway to reach other networks and the DNS servers to resolve names.
Where it matters, and how it fails
For most engineers DHCP is invisible infrastructure — until it misbehaves, at which point it’s the cause of a whole category of “I can’t get on the network” problems. The classic failure modes are worth recognizing: pool exhaustion (more devices than addresses in the scope — new devices simply can’t get on), lease conflicts or a rogue DHCP server (an unauthorized DHCP server on the network handing out wrong or malicious configs — a real attack vector, since a rogue server can point victims at an attacker’s DNS or gateway), and the tell-tale APIPA address (a device that gets a 169.254.x.x self-assigned address means it couldn’t reach a DHCP server at all — a instantly recognizable “DHCP is down or unreachable” symptom). In cloud environments, DHCP is handled by the platform: your VPC automatically provides DHCP so instances get private IPs from the subnet range without you running a server, though AWS exposes DHCP option sets to customize things like the DNS servers instances are told to use. The security angle — rogue DHCP servers and DHCP starvation attacks — is why enterprise switches offer DHCP snooping to only trust DHCP responses from authorized ports.
What people get wrong
- Not recognizing the symptoms — a
169.254.x.x(APIPA) address means the device never reached a DHCP server; it’s a diagnosis, not a valid network address. - Ignoring rogue DHCP risk: an unauthorized DHCP server can redirect victims’ DNS/gateway — use DHCP snooping on managed networks to prevent it.
- Undersized address pools — a scope too small for the device count causes intermittent “can’t connect” failures as the pool exhausts.
Primary source: RFC 2131: Dynamic Host Configuration Protocol
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.