3.2 IP, MAC, DNS, and DHCP in Simple Terms
Four names, four different jobs
A laptop joining a network needs four independent facts before a browser works. A MAC address such as a4:83:e7:2b:05:c1 identifies the physical interface and is burned in or locally administered; it is used only for delivery on the local segment. An IP address such as 192.168.1.20/24 identifies the host logically, tells it which subnet it belongs to, and is what routers route on. DHCP hands out that IP address plus the gateway, DNS server, and lease time. DNS then converts example.com into 192.0.2.1 so the IP layer has something to send to. Each failure mode looks different, so naming the layer correctly is half of troubleshooting.
DHCP step by step: the DORA exchange
With no address yet, the client cannot unicast, so it broadcasts on UDP port 67 from its own port 68. Step 1, Discover: DHCPDISCOVER with source IP 0.0.0.0 and destination 255.255.255.255, carrying client MAC a4:83:e7:2b:05:c1. Step 2, Offer: a server with a free address replies DHCPOFFER proposing 192.168.1.20, mask 255.255.255.0, router 192.168.1.1, DNS 192.168.1.1, lease 86400 seconds. Step 3, Request: the client broadcasts again, naming the chosen server identifier so that every other DHCP server retracts its offer. Step 4, Acknowledge: the server confirms with DHCPACK, and the interface applies the lease. Renewal happens unicast at half the lease (T1, roughly 43200 s) directly to the server. Two attacks live in this design: a rogue server can answer Offers first because the client accepts the first reply it sees, and a starvation attack can exhaust the pool by requesting addresses with random MACs.
DNS resolution, hop by hop
A lookup for mail.example.com starts in the local cache and the /etc/hosts file, then asks the stub resolver's configured server over UDP 53. A recursive resolver such as 1.1.1.1 then iterates: query a root server, get a referral to the com TLD servers, get a referral to the authoritative server, receive the A record 192.0.2.1 plus a TTL it will cache. AAAA returns IPv6, MX returns mail exchangers with priorities, TXT carries SPF and DKIM policy, and PTR lookups in in-addr.arpa give reverse names. Cache entries honour TTL, and the dig +trace example.com command shows each referral.
Why these four interact badly
ARP glues the two address families together by asking "who has 192.168.1.1? tell 0.0.0.0", and ARP replies are never authenticated, so a host that lies becomes the gateway for its subnet. Static ARP entries, RA guard, DHCP snooping on managed switches, and DNSSEC validation on resolvers are the standard countermeasures, because none of MAC, DHCP, or DNS proves identity on its own.
Architecture Diagram
Key Takeaways
- MAC addresses are per-segment identifiers; IP addresses are the routable, end-to-end ones.
- DHCP uses UDP
67/68and broadcasts because the client has no address yet. - DORA is Discover, Offer, Request, Acknowledge; renewal is unicast at half the lease.
- DNS is a cached referral chain: root, TLD, authoritative, then TTL-bound cache entries.
- ARP, DHCP, and DNS are unauthenticated by default, so rogue servers and spoofing are realistic.