When you type google.com into your browser, your laptop does not send a DNS query to the root servers. It doesn’t walk the DNS tree. It doesn’t do recursive resolution.
Your laptop is a stub resolver. It knows how to ask questions, but it doesn’t know how to find answers.
Here’s what actually happens:
- Your laptop asks your configured DNS server (usually your router or ISP): “What’s the IP for google.com?”
- That DNS server—the recursive resolver—does all the heavy lifting
- The recursive resolver walks the DNS tree, starting from the roots
- Your laptop gets back a simple answer: “It’s 142.250.190.14”
sequenceDiagram
participant Laptop as Laptop (Stub)
participant Rec as ISP/Router (Recursive)
participant Root as Root Server (.)
participant TLD as TLD Server (.com)
participant Auth as Auth Server (google.com)
Laptop->>Rec: "What's the IP for google.com?"
note over Rec: The recursive resolver takes over
Rec->>Root: "Where is .com?"
Root-->>Rec: "Ask these TLD servers"
Rec->>TLD: "Where is google.com?"
TLD-->>Rec: "Ask these Auth servers"
Rec->>Auth: "What's the IP for google.com?"
Auth-->>Rec: "It's 142.250.190.14"
Rec-->>Laptop: "It's 142.250.190.14"
The distinction matters because when DNS breaks, you need to know where to look. If nslookup google.com fails, the problem could be:
- Your stub resolver configuration (wrong DNS server)
- Network connectivity to your recursive resolver
- The recursive resolver itself having issues
- Something wrong in the authoritative chain for google.com
Most people assume it’s the last one. It’s usually the first three.
The Circular Dependency That Breaks Everything#
Here’s a brain teaser: How do you find the nameservers for .com if you need working DNS to resolve the nameserver hostnames?
The .com zone says its nameservers are at a.gtld-servers.net, b.gtld-servers.net, etc. But to resolve a.gtld-servers.net, you need to query the .net nameservers. And to find the .net nameservers, you need to resolve their hostnames, which might be in .com.
This is the circular dependency that would make DNS impossible if not for glue records.
Glue records are IP addresses stored in the parent zone to bootstrap the resolution process. When the root servers tell you about the .com nameservers, they don’t just give you the hostnames—they include the IP addresses:
com. 172800 IN NS a.gtld-servers.net.
a.gtld-servers.net. 172800 IN A 192.5.6.30That second line is the glue record. It lets you contact the .com nameservers directly, without having to resolve their names first.
You can see glue records in action with dig:
dig +trace google.comLook for the additional section in each response. Those are the glue records that keep the DNS world spinning.
When 512 Bytes Isn’t Enough#
DNS was designed in 1983 when networks were slow and unreliable. UDP packets bigger than 512 bytes were likely to get fragmented or dropped, so DNS responses were limited to 512 bytes.
That works fine for simple queries, but modern DNS responses can be much larger. DNSSEC signatures, IPv6 addresses, and multiple A records can easily exceed 512 bytes.
EDNS (Extension Mechanisms for DNS) fixes this by letting clients and servers negotiate larger UDP packet sizes:
dig +bufsize=4096 @8.8.8.8 google.comThe problem is middleboxes—firewalls, routers, and other network devices—that don’t understand EDNS. They see a larger DNS packet and either drop it or mangle it.
When EDNS fails, DNS falls back to TCP, which works but is slower. Some broken implementations just timeout instead.
If you’re debugging intermittent DNS failures, especially for DNSSEC-enabled domains, check if EDNS is working:
dig +edns=0 @8.8.8.8 example.com
dig +bufsize=4096 @8.8.8.8 example.comIf the second one fails but the first succeeds, you’ve found your culprit.
The Privacy Leak You Didn’t Know About#
Traditional recursive DNS resolvers leaked more information than necessary. When you asked for mail.example.com, older resolvers would query the root servers for mail.example.com, revealing the full query to everyone in the resolution chain.
QNAME minimization fixes this privacy leak. Modern resolvers only reveal the minimum information needed at each step:
- Query root servers: “Where’s
.com?” - Query
.comservers: “Where’sexample.com?” - Query
example.comservers: “Where’smail.example.com?”
Each authoritative server only sees the part of the query they need to answer. The root servers never see that you’re looking for the mail server.
You can test if your resolver supports QNAME minimization, though it requires packet capture or specialized tools since the behavior is transparent to stub resolvers.
Cache Poisoning: The Attack That Never Died#
Cache poisoning attacks exploit the fact that DNS responses can arrive out of order. An attacker sends fake responses that arrive before the legitimate ones, causing the resolver to cache incorrect information.
The attack works because traditional DNS had predictable query IDs and source ports. An attacker could guess the ID and flood the resolver with fake responses.
Modern defenses include:
- Randomized query IDs (16 bits of entropy)
- Randomized source ports (another 16 bits)
- DNSSEC cryptographic validation
But DNSSEC adoption is still incomplete, and many resolvers don’t validate signatures even when they’re available.
You can check DNSSEC validation with:
dig +dnssec @8.8.8.8 cloudflare.com
dig +dnssec @8.8.8.8 dnssec-failed.orgThe first should return RRSIG records. The second should fail with SERVFAIL if your resolver properly validates DNSSEC.
When DNS Lies#
DNS has no built-in concept of truth. Authoritative servers can lie, and recursive resolvers will happily cache and serve the lies.
This happens more often than you’d think:
- Misconfigured authoritative servers returning wrong answers
- DNS hijacking by ISPs or governments
- Split-horizon DNS returning different answers based on source IP
- TTL manipulation causing stale data to persist
The most insidious failures happen when authoritative servers return different answers to different queries, making problems intermittent and hard to reproduce.
DNS Forwarders: The Complexity Multiplier#
Many networks use DNS forwarders—recursive resolvers that don’t do full recursion, but instead forward queries to upstream resolvers. This creates complex dependency chains that can fail in unexpected ways.
Your query path might look like:
Laptop → Router → ISP Resolver → Google Public DNS → Authoritative Server
Each hop adds latency, caching behavior, and potential failure modes. When troubleshooting, you need to test each link in the chain:
dig @192.168.1.1 example.com # Router
dig @your-isp-dns example.com # ISP
dig @8.8.8.8 example.com # Public DNS
dig @ns1.example.com example.com # AuthoritativeThe dig Flags You Should Know#
Most engineers know dig google.com. Here are the flags that separate competent troubleshooters from people who just restart things:
# See the full resolution path
dig +trace google.com
# Test specific record types
dig +short MX google.com
dig +short TXT google.com
# Ignore cached results
dig +nocache @8.8.8.8 google.com
# See the query and response packets
dig +qr +nocomments google.com
# Test DNSSEC validation
dig +dnssec +multiline google.com
# Check authoritative vs cached answers
dig google.com
dig @ns1.google.com google.comThe DNS and BIND Cookbook remains the definitive reference for this level of DNS troubleshooting, with practical examples you’ll actually use in production.
Making DNS Work For You#
Understanding DNS at this level isn’t academic exercise. When your application is timing out intermittently, when your CDN is serving stale content, or when your monitoring shows mysterious connectivity failures, the problem is often DNS.
The difference between network engineers who can fix these problems and those who can’t isn’t intelligence or experience. It’s understanding what DNS actually does versus what people think it does.
DNS is not magic. It’s a distributed database with caching, TTLs, and complex failure modes. Once you understand the mechanics, the failures make sense and the solutions become obvious.