Networking › Module 6 › Lesson 3
DHCP — Automatic Addressing
How devices get IP, gateway, and DNS settings automatically—and what can go wrong
Opening
The LAN that configures itself — and the server you did not choose
Most hosts never get a typed static IP. They boot, they ask, they receive: address, mask/prefix, default gateway, DNS servers, lease time. That protocol is DHCP (Dynamic Host Configuration Protocol). When it works, ip addr and ip route look "just right." When it fails, users say "Wi-Fi is connected but nothing loads." DHCP is also a trust decision. Whoever answers the ask can push a gateway and a DNS. A rogue DHCP server is a risk — wrong DNS is a phishing path — not a lab you run against a café. This lesson is DORA mechanism, leases, options, and read-only inspection of YOUR resolver and route. You will not stand up a rogue server. You will not attack anyone's DHCP.
1. DORA: Discover, Offer, Request, Ack
Remember DORA — four messages, usually UDP, client 68, server 67, with broadcasts until the client has an address: 1) Discover — the client (often 0.0.0.0) broadcasts: is there a DHCP server? It may hint at a previously used address. 2) Offer — a server offers an IP plus options: subnet mask, router (gateway), domain-name-servers, lease time, maybe NTP or a domain name. 3) Request — the client asks to use that offer (important when two servers offered; the Request names which server/offer). 4) Acknowledge — the server confirms the lease. The client configures the iface: inet CIDR, default via, resolver list. Only after Ack does ARP for the gateway make sense in the usual story. If Discover never gets an Offer, the host may sit on a 169.254/16 link-local (APIPA) address — "connected" in the GUI, no real gateway, no useful DNS. That is a DHCP failure, not "the fiber is cut." Renewals happen later with unicast to the same server so the address stays stable while in use. When the lease dies without renewal, the address returns to the pool.
2. Options, leases, and rogue DHCP as risk
The IP is only one option. Default gateway (router option) is how you leave the LAN — the same via you read with ip route. DNS servers are how names become IPs — the same path getent/nslookup use. A perfect IP with a lying DNS is a phishing machine: the user types bank.example and lands on an attacker page if TLS is ignored or a similar-name trap works. Wrong gateway is a local MITM path related to the ARP lesson: your "internet" first hop is not the router you think you bought. Rogue DHCP: any device that answers Discover can win if it is faster or if the real server is quiet. This is RISK awareness for defenders, not an attack lab. Do not practice offering DHCP on a network you do not own. Do not run a second server "to see who wins" on school Wi-Fi. Defender habits: know which box is supposed to run DHCP (usually YOUR router). Know the real gateway IP and MAC from a baseline. On managed LANs: DHCP snooping, authorized server ports, alerts on unexpected DHCP offers. On your host: ip route and resolvectl status or cat /etc/resolv.conf are read-only checks — do they still match the gateway and DNS you expect?
3. Wrong vs right: attack DHCP vs read your lease path
Worked failure mode — turning DORA into a weapon. Read your own route and resolver. Do not offer leases to strangers.
Wrong
You start a DHCP server on a laptop in a café "to learn DORA," pushing your DNS to whoever Discovers. That is hijacking other people's configuration. Or you edit /etc/resolv.conf into a random public resolver on a production box without a change window and call it a lab.
Right
ip route shows default via — compare to the gateway you expect on a LAN you own. resolvectl status or cat /etc/resolv.conf shows which DNS this host trusts — read, do not blindly overwrite. If both suddenly point at an unknown device, treat it as rogue-DHCP/phishing risk and investigate as a defender. No rogue-server lab.
4. Practical: route and resolver — read only
You are inspecting what DHCP (or static config) already applied. You are not dhclient -r as a game on a shared link, not installing a DHCP daemon for "practice offers," not scanning for other DHCP servers on a foreign LAN.
Command guide
ip route + resolver — READ on YOUR machine
What gateway did this host install? (DHCP router option, if DHCP)
Command — copy this
ip route
default via <GW> dev <IFACE> → should match YOUR real router on a LAN you own
What DNS does this host trust?
Command — copy this
command -v resolvectl >/dev/null && resolvectl status || true
Look for: DNS Servers, Interface, Current DNS Server
Classic file (may be a stub pointing at 127.0.0.53 on systemd-resolved)
Command — copy this
cat /etc/resolv.conf
Optional: lease crumbs on some distros (read only; paths vary)
Optional command
ls "$HOME" >/dev/null
Do not chmod or delete system lease files as "practice."
Windows (your PC): ipconfig /all → DHCP Enabled, DHCP Server, DNS Servers, Default Gateway
NEVER: run a rogue dhcpd/dnsmasq offering DNS on a network you do not own NEVER: DHCP starvation / flood "labs" NEVER: scan other LANs for DHCP servers DORA is a handshake. Rogue Offer is a risk you detect — not a skill you deploy.
Mission: gateway and DNS you actually received
On your VM or WSL, run ip route and either resolvectl status or cat /etc/resolv.conf (read only). Write: (1) default via, (2) at least one DNS server address, (3) one sentence on why a rogue DHCP pushing a different DNS is a phishing risk even if your IP "looks fine." Do not start a DHCP server. Do not attack DORA. Own machine only.
Stuck? Ask Cyberlium AI Mentor
If /etc/resolv.conf only shows 127.0.0.53, ask Cyberlium AI Mentor for a hint — not a rogue-server setup. Try: "Hint only: resolv.conf is 127.0.0.53 — where does resolvectl show the real upstream DNS, and why would a wrong upstream be a phishing risk?"
You can walk DORA, name the lease and the critical options (gateway, DNS), and treat rogue DHCP as a configuration-trust failure — detected by knowing your real gateway and reading the resolver, never by running an attack lab. Next — Lab — Explore Your Local Network — inventory links, addresses, neighbors, listeners, and routes on your own machine, with notes under $HOME/cyberlium-lab.
Knowledge Check
APPLY: A new VM has no inet except 169.254.x.x and no default via. Which DORA step most likely never completed, and what is not the first blame?
Multiple choice
Knowledge Check
APPLY: ip addr looks normal, ip route has a default via, but resolvectl shows a DNS you do not recognize and browser names go to lookalike pages. What risk matches, and what must you not do?
Multiple choice
Knowledge Check
APPLY: True or False: After Discover and Offer, the client still sends Request and waits for Ack before it should treat the IP, gateway, and DNS as its lease.
True or False