DNS and DHCP are both fundamental network services, but they solve entirely different problems.
Let’s see them in action. Imagine a new device, a laptop, just joined your Wi-Fi network.
First, the laptop needs an IP address. It doesn’t know anything about the network yet. So, it broadcasts a DHCP Discover message: "Is there a DHCP server out there? I need an IP address!"
A DHCP server on the network hears this. It replies with a DHCP Offer: "Sure, I can give you 192.168.1.105 for a few hours, along with these DNS server addresses (192.168.1.1 and 8.8.8.8) and a default gateway (192.168.1.1)."
The laptop accepts this offer with a DHCP Request: "Okay, I’ll take 192.168.1.105."
Finally, the DHCP server confirms with a DHCP ACK: "Got it. That IP address is yours for the lease period." Now, the laptop has an IP address and knows how to reach other devices and the internet.
But what if the laptop wants to visit www.google.com? It can’t just send packets to a name; it needs an IP address. This is where DNS comes in.
The laptop sends a DNS Query to one of the DNS servers it learned from DHCP, say 192.168.1.1: "What’s the IP address for www.google.com?"
The DNS server (192.168.1.1) might not know immediately. It checks its cache. If it’s not there, it’ll ask another DNS server, perhaps an upstream resolver like Google’s 8.8.8.8.
8.8.8.8 knows the answer. It replies: "www.google.com is at 172.217.160.142."
The laptop’s DNS server (192.168.1.1) caches this answer and also tells the laptop: "www.google.com is at 172.217.160.142."
Now, the laptop can send packets directly to 172.217.160.142 to load the Google homepage.
The core problem DNS solves is translating human-readable domain names (like www.google.com) into machine-readable IP addresses (like 172.217.160.142). DHCP, on the other hand, automates the assignment of IP addresses, subnet masks, default gateways, and DNS server addresses to devices on a network. Without DHCP, every device would need to be manually configured with this information, which is impractical for anything but the smallest networks.
Think of DHCP as the network’s concierge, handing out room keys (IP addresses) and directions to the front desk (DNS servers). DNS is the phone book, looking up the specific room number (IP address) for a guest’s name (domain name).
The most surprising thing is that when you type www.google.com into your browser, your computer doesn’t directly ask Google’s servers for the IP address. It asks its locally configured DNS server (which it got from DHCP). That local server then acts as an intermediary, querying other DNS servers on your behalf, caching the results to speed up future requests. This distributed, hierarchical system is what makes the global DNS infrastructure resilient and performant.
The next step is understanding how DNS record types (A, AAAA, CNAME, MX, etc.) influence how names are resolved.