DNS and DHCP
Nobody thinks about DNS or DHCP until one of them breaks, and then suddenly "the Internet is down." Usually it isn't. The device didn't get an address, or it got one and can't resolve names. Learning to tell those two apart quickly has saved me more time than almost anything else in networking.
The short version: DHCP gets you onto the network, DNS gets you to the thing you're looking for. Here's what I keep in my head about both.
DNS: who's actually answering?
When you look something up, your computer asks a recursive resolver (your router, your ISP, 1.1.1.1, whatever). If it doesn't already have the answer cached, the resolver walks the hierarchy until it finds the authoritative server for that name, then caches the answer for however long the TTL says.
Keep those two roles separate in your head and you'll fix DNS problems a lot faster. And keep them separate on your servers too. A public authoritative server that also does open recursion for the whole Internet is just asking to be used in an amplification attack.
The records I actually run into
| Record | What it's for |
|---|---|
| A / AAAA | Name to IPv4 / IPv6 address. The bread and butter. |
| CNAME | An alias pointing at another name. Can't live at the zone apex alongside other records. |
| MX | Where mail for the domain goes. |
| TXT | The junk drawer: SPF, DKIM, DMARC, and every "verify you own this domain" string. |
| NS | Which servers are authoritative for the zone. |
| PTR | Reverse lookup, address back to name. Mail servers care about this a lot. |
| SRV | Where a service lives, including the port. |
| CAA | Which certificate authorities are allowed to issue certs for you. |
Split-horizon DNS
Sometimes you want internal clients to get a private address and everyone else to get the public one. Split-horizon DNS does that, and it works fine, but now you have two versions of the same zone to keep straight. If you go this route, write down why. Future you will see the internal answer, compare it to the public one, and assume something is broken.
Troubleshooting DNS
dig is my go-to. A few I use constantly:
dig example.com A dig example.com MX dig +trace example.com # walk the whole delegation chain dig @192.0.2.53 host.example.com # ask one specific server resolvectl query host.example.com # what systemd-resolved thinks
The @server trick is the important one. Ask the authoritative server directly, then ask your resolver. If they disagree, you've already narrowed it down a lot. After that, I go roughly in this order:
- Can the client even reach its resolver?
- Is the resolver handing back an error or a stale cached answer?
- Is the delegation right? Do the parent zone's NS records match reality?
- Is the record actually in the zone, spelled correctly, with the trailing dot where it belongs?
- Is DNSSEC validation failing?
- Is the application caching an old answer on its own? (Browsers and Java both love to do this.)
DHCP: getting onto the network
For IPv4, the exchange is DORA: Discover (client shouts "anyone out there?"), Offer (server offers an address), Request (client says "I'll take it"), Acknowledge (server confirms the lease). Along with the address, the lease hands out the subnet mask, gateway, DNS servers, search domain, and whatever other options you've set.
DHCP relay
DHCP Discover is a broadcast, and broadcasts don't cross routers. If your DHCP server lives on a different VLAN than the clients, the router needs to relay the request. On Cisco that's ip helper-address:
interface Vlan20 description Client Network ip address 10.20.0.1 255.255.255.0 ip helper-address 10.1.0.20
If a new VLAN's clients come up with 169.254.x.x addresses, a missing helper address is the first thing I check.
Tips for keeping DHCP boring
- Keep infrastructure (gateways, switches, printers you hardcoded) out of the dynamic pool. Duplicate addresses are a miserable thing to chase down.
- Use reservations for things that need a predictable address but that you still want managed in one place.
- Match lease time to how fast devices come and go. Guest Wi-Fi wants short leases; an office full of desktops doesn't.
- Watch pool utilization. Pool exhaustion looks exactly like "the Wi-Fi is broken" to everyone else.
- If a network suddenly has the wrong gateway, look for a rogue DHCP server. The usual culprit is a consumer router somebody plugged in by its LAN port.
IPv6 is a little different
IPv6 hosts learn a lot from Router Advertisements, and addressing can come from SLAAC, DHCPv6, or both. Different operating systems handle the combinations differently, especially when it comes to getting DNS servers, so test with whatever clients you actually have before deciding how to do it. There's more on that on the IPv6 page.
Last Modified: October 12, 2026, 11:41 am