Two quiet services do the paperwork every time you open a laptop. DHCP hands your device an address and tells it where the exit is. DNS turns the names you type into the numbers machines actually use. When either one breaks, it looks like "the internet is down," even when every wire is fine.
Common mix-up: DNS does not carry your traffic. It answers one question, "what address is this name?", and then steps out of the way. Your browser connects straight to the address it was given. That's why a DNS failure feels total, yet everything works again the moment a lookup succeeds.
When a laptop connects to Wi-Fi or a cable, it has a link but no identity on the network. It knows its own hardware (MAC) address, burned in or randomized, and nothing else. It has no IP address, doesn't know the subnet, doesn't know which box leads to the rest of the internet, and doesn't know who to ask about names. The Dynamic Host Configuration Protocol, DHCP, fills all of that in.
The trouble is the bootstrapping. To ask a server for an address, you'd normally need to know the server's address and have one of your own. DHCP gets around this with broadcast. The client sends from the "nobody" address 0.0.0.0 to the "everybody on this segment" address 255.255.255.255, over UDP from port 68 to port 67. Every device on the local network receives it. Only DHCP servers care.
The conversation has four steps, remembered as DORA:
On a home network the server is almost always a feature of the router. In an office it's usually a dedicated server, and because broadcasts don't cross routers, each subnet's router runs a small relay agent that catches Discovers and forwards them, as ordinary unicast packets, to the central server.
| Setting | Example | What the device does with it |
|---|---|---|
| Address | 192.168.1.57 | Its own identity on this network. Goes in the source field of every packet it sends. |
| Subnet mask | 255.255.255.0 (/24) | Tells it which addresses are neighbors it can reach directly, and which are "somewhere else" (see Chapter 03). |
| Default gateway | 192.168.1.1 | Where to send anything that isn't a neighbor. Usually the router. |
| DNS servers | 192.168.1.1 | Who to ask when a name needs turning into an address. Often the router again, which passes questions on. |
| Lease time | 86,400 s (24 h) | How long the address is on loan before it must be renewed. |
| Extras | domain, NTP, … | A search domain, time servers, and dozens of other optional "options." |
DHCP messages share a fixed layout inherited from BOOTP, its 1980s predecessor: fields for the client's hardware address (chaddr), the address being offered (yiaddr, "your IP address"), the relay agent's address (giaddr), and a transaction ID (xid) the client picks at random so it can match replies to its own requests. Everything else rides in a list of numbered options at the end.
Option 53 says which kind of message this is (1 Discover, 2 Offer, 3 Request, 5 Ack, 6 Nak, 7 Release). Option 1 is the subnet mask, 3 the router, 6 the DNS servers, 51 the lease time, 54 the server identifier, and 50 the address the client is asking for. Option 55, the "parameter request list," is the client saying which settings it would like; servers use it to tailor replies, and it's distinctive enough that network tools can often guess a device's operating system from it.
A server may also send a Nak: "no, you can't have that address." It typically happens when a laptop wakes on a different network and tries to reclaim the address it had at home. The client drops the address and starts again with Discover.
A DHCP address is a lease. The server lends it for a fixed time, and the client has to keep renewing. That way addresses from devices that left (a guest's phone, a laptop that went home) drift back into the pool without anyone cleaning up. Home routers commonly use leases of a day; coffee-shop networks use an hour or less, because their crowd turns over fast.
The standard sets two checkpoints on the clock:
Between checkpoints the client doesn't hammer the server. While renewing it waits half the remaining time to T2 before retrying, and while rebinding half the remaining time to expiry, never less than 60 seconds. You can watch all of it in the instrument below.
On Windows, ipconfig /release sends a Release message and drops the address, and ipconfig /renew runs the exchange again. ipconfig /all shows "Lease Obtained" and "Lease Expires" for each adapter. On macOS, System Settings → Network → your connection → Details → TCP/IP → "Renew DHCP Lease" does the same, and ipconfig getpacket en0 prints the last Ack in full. On most Linux systems, nmcli or the DHCP client's own command does it.
A client reconnecting to a network it has seen before usually skips Discover and goes straight to a Request for its old address (the INIT-REBOOT state). If the server agrees, it's a two-message exchange. That's why rejoining your home Wi-Fi feels instant.
Press Connect, then fast-forward. The ladder shows every message the laptop and the two servers exchange; the bar underneath is the lease, with T1 and T2 marked. Switch the servers off mid-lease and watch renewing turn into rebinding, then expiry, then a self-assigned 169.254 address. Server B is a failover partner that shares server A's lease records.
Retry timing follows RFC 2131. The four unanswered Discovers before falling back to 169.254 are a simplification; real clients vary.
If a client's Discovers go unanswered, it retries with growing gaps: about 4 seconds, then 8, then 16, and so on, with a little randomness so a roomful of devices rebooting after a power cut don't all shout at once. If still nothing comes back, most operating systems give themselves an address from 169.254.0.0/16, the IPv4 link-local range. Microsoft calls this APIPA, Automatic Private IP Addressing. The device picks a random address in the range, checks with ARP that nobody else is using it, and carries on.
A link-local address lets devices on the same cable or Wi-Fi talk to each other with no server at all, which is how two laptops joined by a single Ethernet cable can still share files. But there's no gateway, so nothing beyond the local segment is reachable. If you ever see 169.254.x.x in ipconfig, read it as a plain message: DHCP failed here. Check the cable, the Wi-Fi association, or whether the router's DHCP server is switched on. Windows keeps looking for a server in the background, every five minutes, and swaps the 169.254 address out the moment one answers.
Reservations go the other way: you tell the DHCP server to always give the same address to the same MAC address. The printer, the NAS and the home server get predictable addresses, but they're still configured by DHCP, so if you change the DNS server or the gateway, they pick the change up at their next renewal. That's usually better than typing a static address into the device itself, which the server knows nothing about and might hand to someone else. If you do set static addresses, put them outside the range the server lends from.
The last failure is too many servers. DHCP has no authentication: whichever server answers first usually wins. Plug a second router into your network with its DHCP server switched on, and half your devices may get settings from one and half from the other. That second router is also a second layer of NAT, and Chapter 06 and Chapter 08 come back to what that does to remote access.
IPv6 hosts usually don't need a DHCP server for an address. The router periodically multicasts a Router Advertisement announcing the network's 64-bit prefix, and each host builds the rest of its own address. This is SLAAC, stateless address autoconfiguration (RFC 4862). Modern systems use randomized, regularly changing host parts for privacy.
DHCPv6 (RFC 8415) still exists, for networks that want central control or need to hand out extra settings. Router Advertisements can carry DNS servers too (RFC 8106), so a home network can run IPv6 with no DHCPv6 at all. Every IPv6 interface also always has a link-local address in fe80::/10, the counterpart of 169.254, except that there it's normal rather than a sign of failure.
Packets carry addresses, not names. Something has to translate www.example.com into 192.0.2.10. In the early ARPANET that was a single text file, HOSTS.TXT, that every site downloaded from one place. By the early 1980s it was changing faster than anyone could copy it, and in 1983 Paul Mockapetris designed its replacement: the Domain Name System.
The key idea is delegation. Nobody holds the whole phone book. Read a name from right to left and each dot is a handoff:
Your laptop doesn't walk this tree itself. It runs a tiny stub resolver that asks one question of one server, the DNS server DHCP gave it, and waits. That server, a recursive resolver run by your ISP, a public service, or forwarded through your router, does the legwork. It asks a root server, which refers it to the TLD servers; it asks those, which refer it to the domain's authoritative servers; it asks those and finally gets the answer. Then it hands the answer back to the stub and keeps a copy.
A root or TLD server doesn't say "I don't know." It sends a referral: an answer with no answer section, just a list of NS (name server) records for the next zone down, often with their addresses attached. Those attached addresses are called glue, and they matter when the name server lives inside the zone it serves. If example.com's server were ns1.example.com, you'd need to resolve example.com to find the server for example.com. Glue in the parent zone breaks the loop.
How does a resolver find the root in the first place? It ships with a small "root hints" file listing the thirteen names and their addresses, and refreshes it from the root itself at startup. Those addresses almost never change.
A fully qualified name really ends in a dot: www.example.com.. Software usually adds it silently. When a name without a dot at the end fails, a resolver may try appending a search domain from DHCP, which is how typing just printer can find printer.home.arpa.
Walking the tree takes three or four round trips, perhaps 100 milliseconds. Doing that for every image on every web page would be miserable, so every answer carries a time to live (TTL), a number of seconds the owner says it's safe to remember. The resolver caches the answer until the TTL runs out, and the next person who asks gets it in about a millisecond. Your operating system and browser keep their own small caches too.
The referrals are cached as well, and those TTLs are long: the delegation of com from the root lasts two days. So a busy resolver almost never talks to the root. Usually it already knows the com servers, and often the domain's own servers, and goes straight to the last step.
TTL is a tradeoff the domain owner makes. A long TTL means fewer queries and faster answers, but a change takes that long to reach everyone. A short TTL makes changes visible quickly but sends more traffic to the authoritative servers. A common trick before moving a website: drop the TTL to five minutes a day ahead, make the move, then raise it again. When people say a DNS change "takes 48 hours to propagate," what they're actually waiting for is old cached copies to expire.
"No such name" gets cached too. A negative answer (NXDOMAIN) is remembered for a time set by the zone, so a typo doesn't trigger a fresh walk every time.
| Record | Example | Meaning |
|---|---|---|
| A | example.com → 192.0.2.10 | An IPv4 address for this name. |
| AAAA | example.com → 2001:db8::10 | An IPv6 address. Four A's because the address is four times as long. |
| CNAME | www → shop.example.net | An alias: "this name is really that one, go look it up." The resolver follows it. |
| MX | 10 mail.example.com | Where to deliver email for the domain, with a preference number (lower is tried first). |
| TXT | "v=spf1 mx -all" | Free text, used mostly for proofs and policies: SPF mail rules, domain-ownership checks. |
| NS | ns1.example.net | Which servers are authoritative for this zone. The links that hold the tree together. |
| PTR | 10.2.0.192.in-addr.arpa | The reverse: address back to name. Used by logs, mail servers and traceroute. |
Classic DNS questions and answers travel in single UDP packets to port 53: no handshake, one packet each way, which is why a lookup can finish in one round trip (Chapter 05 explains why that matters). Plain DNS over UDP was originally limited to 512 bytes; the EDNS(0) extension lets the two sides agree on larger packets. If an answer still doesn't fit, the server sets a "truncated" flag and the resolver retries over TCP.
Plain DNS is unencrypted. Anyone on the path can see which names you look up. DNS over TLS (port 853) and DNS over HTTPS wrap the same questions in encryption between your device and the resolver. The resolver itself still sees everything, which is why choosing one is a matter of trust.
Type a name and press Look up. The resolver's cache starts empty, so the first lookup walks root → TLD → authoritative. Look up the same name again and it comes straight from cache; look up a sibling name and only the last step is needed. Fast-forward the clock to watch TTLs run out. The zones are simulated: names under example.com, example.net and example.org follow a fixed zone file, and any other name gets a made-up answer from a documentation range.
Delays are typical, not measured: about 12 ms to the resolver, 18 to a root, 24 to a TLD, 30–80 to an authoritative server.
Nearly everything you do starts with a name. If lookups fail, every app fails at once, in the same way, and the message is almost never "DNS failed." Browsers say "This site can't be reached." Mail apps say they can't find the server. Games say you're offline. It looks exactly like a dead connection, but the cables, the Wi-Fi and the route out are all fine.
Common causes, roughly in order of how often they bite at home:
The test that separates DNS from everything else takes ten seconds: reach something by number, then by name. If ping 1.1.1.1 answers and ping example.com says it can't find the host, your connection is fine and name resolution is the problem. nslookup example.com shows which server answered (or didn't); nslookup example.com 9.9.9.9 asks a different one directly, which tells you whether it's your resolver or the domain.
At home there are usually four caches between you and the authoritative server: the browser's, the operating system's (on Windows, ipconfig /displaydns shows it and ipconfig /flushdns empties it), the router's forwarder, and the ISP or public resolver. A stale answer can be hiding in any of them.
The DNS server DHCP hands you is often just the router's LAN address. The router isn't a full resolver; it's a forwarder that relays questions to whatever its own WAN-side DHCP told it, and caches answers. If you change DNS servers in the router's settings, every device picks it up at its next lease renewal. If you change it on one laptop, only that laptop changes, and it bypasses the router's cache.
Tools like dig +trace example.com (macOS and Linux) do the full walk themselves, starting from the root, and print every referral: the same path Instrument 2 draws.