At 07:55 a lab of thirty Chromebooks powers on. Twenty-two get addresses. Eight show 169.254.x.x
and a "no internet" icon. The access point is fine, the switch is fine, the firewall is fine. The
problem is a scope that holds 254 leases and a room that opens thirty devices at once, three times a
day.
DHCP and DNS are the two services every other service assumes. Neither is glamorous, and both are worth understanding properly, because their failure modes are distinct and diagnosable.
DHCP: four packets and an address
DHCP is how a device that knows nothing about the network gets enough information to participate in it. The exchange is broadcast, because the client does not yet have an address to be unicast to:
| Step | Direction | Message | What it carries |
|---|---|---|---|
| 1 | Client → broadcast | Discover | "Is there a DHCP server?" |
| 2 | Server → client | Offer | A proposed address and options |
| 3 | Client → broadcast | Request | "I will take that one" |
| 4 | Server → client | Acknowledge | Lease confirmed, options finalized |
The four initials — DORA — are worth memorizing, because the point of failure tells you what is wrong. No Offer means no server heard the broadcast. An Offer but no Ack usually means a second server disowned the request, or the network dropped the unicast reply.
Options are the part that matters
An address alone is useless. The server also sends options that tell the client how to use it:
| Option | Meaning | Typical value |
|---|---|---|
| 1 | Subnet mask | 255.255.248.0 |
| 3 | Default gateway | 10.40.8.1 |
| 6 | DNS servers | 10.0.0.3, 10.0.0.4 |
| 15 | Domain name | marionisd.net |
| 42 | NTP servers | 10.0.0.3 |
| 119 | Domain search list | marionisd.net |
Two of these cause most of the outages I have seen. If option 3 is wrong, the device has an address and cannot leave its subnet. If option 6 points at a resolver that is unreachable from that VLAN, the device has an address, a working gateway, and no names — which looks exactly like "the internet is down" to a user.
Leases expire, and they expire in clusters
A lease is granted for a fixed time, typically 8 to 24 hours in a district. Clients renew at 50% of the lease and rebind at 87.5%. Devices that were imaged together and deployed together renew together. If your pool is undersized, the failures will cluster at the same times every day, which is a useful clue and a terrible user experience.
Relay: how one server serves forty VLANs
DHCP Discover is a broadcast, and broadcasts do not cross routers. Yet most districts run one or two DHCP servers for the entire network.
The answer is the DHCP relay, sometimes called an IP helper. The router receives the broadcast on an interface, wraps it in a unicast packet to the server, and records which subnet it came from. The server picks a scope for that subnet, and the reply is relayed back. Option 82 carries the circuit information, which is how a switch can tell the server which port a request arrived on.
This is why a VLAN without a helper address gets no addresses, even though the DHCP server is healthy and has a perfectly good scope waiting.
Reservations, and why MAC addresses are not identity
A reservation ties an address to a MAC address so a printer or a camera keeps the same IP. It is convenient and it is not authentication: MAC addresses are trivially spoofed, and a reservation does nothing to stop a device from configuring itself statically.
For anything that matters — servers, network gear, controllers — set the address statically on the device and document it. Reservations are for devices that cannot hold a static configuration and whose address you would rather not chase.
DNS: names, records, and caching
DNS is a distributed database with one job: map names to records. The client is a stub resolver that asks a recursive resolver; the resolver walks the hierarchy or answers from cache.
The record types you will actually meet:
| Type | Answers | Example |
|---|---|---|
| A | IPv4 address | www → 203.0.113.10 |
| AAAA | IPv6 address | www → 2001:db8::10 |
| CNAME | Alias to another name | help → www |
| MX | Mail server | marionisd.net → mail.example |
| TXT | Arbitrary text | SPF, DKIM, domain verification |
| SRV | Service location | _ldap._tcp.dc._msdcs → a domain controller |
| PTR | Reverse lookup | 10.0.113.203 → www |
TTL controls how long a resolver may cache an answer. Short TTLs make changes propagate quickly and increase query volume; long TTLs do the opposite. During a migration, lower the TTL a day before you move the record, not after.
Active Directory does not work through public DNS
Domain-joined machines find their domain controllers through SRV records that exist only in the
internal DNS zone. If a staff laptop is handed 1.1.1.1 as its resolver, logins fail or take ninety
seconds, Group Policy stops applying, and the error messages point at the domain rather than at DNS.
Domain-joined devices must use the domain controllers as their resolvers. This is not a preference.
The two services depend on each other
DHCP hands out the DNS server address. DNS resolves the name of the DHCP server, the domain controller, and the update server. A mistake in either one produces symptoms in the other.
Worked example: a Chromebook joins the staff SSID
- The device associates, and its DHCP client broadcasts a Discover on VLAN 106.
- The gateway relays it to
10.0.0.3with the subnet recorded. - The server offers
10.40.60.84/22, gateway10.40.60.1, DNS10.0.0.3, domainmarionisd.net. - The device requests the offer; the server acknowledges; the lease starts.
- The device queries
10.0.0.3foraccounts.google.com; the resolver answers from cache or recurses. - The device opens TCP 443, and the article before this one takes over.
Six steps, two protocols, and one dependency chain. If step 3 hands out the wrong resolver, step 5 fails and step 6 never happens.
What breaks in production
- Scope exhaustion. The pool is smaller than the peak device count. Symptom:
169.254.x.xaddresses, clustered at class-change times. - Rogue DHCP server. A personal router plugged into a wall port hands out its own scope and gateway. Symptom: a handful of devices with working local access and no internet. DHCP snooping, with trusted ports configured, is the fix.
- Missing relay. A new VLAN has a scope but no helper. Symptom: no addresses at all on that VLAN.
- DNS forwarder loop. Two resolvers forwarding to each other, or a forwarder pointing at itself. Symptom: queries time out after exactly the resolver timeout, every time.
- Public DNS on domain clients. Logins are slow or fail, and DNS looks "fine" because public queries work. The SRV records are simply not there.
- Two DHCP servers, one scope, no split. Both answer, both offer, and clients get addresses from whichever replied first. Use a failover relationship or split the range explicitly.
Checklist
- Every VLAN with clients has a scope, a relay, and a gateway that matches the subnet.
- Pool size is peak devices plus at least 20%.
- Option 6 points at resolvers that are reachable from that VLAN.
- Domain-joined devices get the domain controllers, never a public resolver.
- DHCP snooping is enabled with an explicit trusted-port list.
- You know your lease time and can explain why it is that number.
Next
You now have the four steps, the arithmetic behind an address, the boundary a VLAN draws, and the two services that make the rest possible. The next series applies all of it to the physical plant: Switching and the Campus LAN, starting with what a switch actually does with a frame.