How DNS Resolution Works?
Understanding DNS Resolution Using dig: A Practical, System‑Level Guide
When you type google.com into your browser, an entire distributed system quietly springs into action. Within milliseconds, your computer figures out which IP address to talk to, even though the internet fundamentally works on numbers, not names.
This article walks you through how DNS really works, step by step, using the dig command as a lens. By the end, you’ll not only know what happens, but why DNS is designed this way — a perspective that’s invaluable for backend engineers, DevOps, and system designers.
DNS: The Internet’s Phonebook 📖
Computers communicate using IP addresses like:
142.250.195.14
Humans prefer names like:
google.com
DNS (Domain Name System) exists to bridge this gap. It is a globally distributed, hierarchical database that maps human‑readable domain names to IP addresses.
Key goals of DNS:
Scalability (billions of queries/day)
Decentralization (no single point of failure)
Performance (fast lookups via caching)
Think of DNS as a federated phonebook, not a single database.
Why Name Resolution Exists
Imagine if:
Every app had to hard‑code IP addresses
IP changes required redeploying the entire internet
DNS solves:
IP mobility (servers change, names stay)
Load balancing (multiple IPs per name)
Fault tolerance (failover via DNS)
In system design terms: DNS decouples identity from location.
Introducing dig: Your DNS Debugger 🔍
dig (Domain Information Groper) is a DNS inspection tool. It shows you exactly:
Which servers are queried
What records are returned
How long resolution takes
Unlike nslookup, dig is:
Script‑friendly
Explicit and verbose
Preferred by engineers
Basic syntax:
dig <domain> <record-type>
DNS Resolution Happens in Layers
DNS resolution follows a strict hierarchy:
Root Servers
↓
TLD Servers (.com, .org, .in)
↓
Authoritative Servers (google.com)
Each layer only knows who to ask next, not the final answer.
This design keeps DNS:
Scalable
Delegated
Maintainable
Step 1: dig . NS — Root Name Servers 🌍
dig . NS
What this means
.represents the DNS root zoneNSrecords tell us who controls the root
What you’ll see
. NS a.root-servers.net.
. NS b.root-servers.net.
...
Key insight
There are 13 logical root servers (A–M)
Each is backed by anycasted global infrastructure
Root servers do not know IPs for google.com.
They only know:
“Ask the
.comservers.”
Step 2: dig com NS — TLD Name Servers
dig com NS
What this shows
- The name servers responsible for
.com
Example output:
com. NS a.gtld-servers.net.
com. NS b.gtld-servers.net.
Responsibility of TLD servers
They don’t know IPs for domains
They know which authoritative servers manage
google.com
System design note:
TLD servers act as delegation directories, not databases of records.
Step 3: dig google.com NS — Authoritative Name Servers
dig google.com NS
What you learn here
google.com. NS ns1.google.com.
google.com. NS ns2.google.com.
These servers:
Are controlled by Google
Hold the source of truth for
google.com
They store:
A / AAAA records
MX records
TXT records
CNAMEs
Authoritative servers are where answers live.
Step 4: dig google.com — The Full Resolution Flow
dig google.com
What happens behind the scenes
Your recursive resolver (ISP / local / 8.8.8.8):
Queries a root server
Gets referred to
.comTLDQueries
.comTLD serverGets referred to Google’s authoritative server
Queries authoritative server
Receives the final IP address
Caches the result
Example answer section
google.com. 300 IN A 142.250.195.14
TTL (300) controls how long caching is allowed.
How Recursive Resolvers Tie Everything Together 🧠
Browsers do not walk the DNS hierarchy.
Instead, they ask a recursive resolver, which:
Performs the full lookup
Caches aggressively
Protects root/TLD servers from overload
This is why:
DNS is fast
Root servers are not overwhelmed
Recursive resolvers are the unsung heroes of the internet.
Mapping dig Commands to DNS Lookup Stages
dig Command | DNS Layer | Purpose |
dig . NS | Root | Discover TLD servers |
dig com NS | TLD | Discover authoritative servers |
dig google.com NS | Authoritative | Identify source of truth |
dig google.com | Full resolution | Get IP address |
DNS and Real‑World Browser Requests 🌐
When you hit Enter in a browser:
DNS resolution happens
TCP handshake starts
TLS negotiation occurs
HTTP request is sent
If DNS fails, nothing else starts.
That’s why DNS is:
A critical dependency
A frequent outage root cause
A core system‑design primitive
Diagrams
1. DNS hierarchy: Root → TLD → Authoritative servers
┌─────────────────────────┐
│ Root Servers (.) │
│ a.root-servers.net │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ TLD Servers (.com) │
│ a.gtld-servers.net │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Authoritative Servers │
│ (google.com) │
│ ns1.google.com │
└─────────────────────────┘
2. Step-by-step DNS resolution flow for google.com
[ Browser ]
│
▼
[ Recursive Resolver ] (ISP / 8.8.8.8)
│
│ ① Who handles .com?
▼
[ Root Server ]
│
│ ② Ask the .com TLD
▼
[ TLD Server (.com) ]
│
│ ③ Who is authoritative for google.com?
▼
[ Authoritative Server ] (ns1.google.com)
│
│ ④ Here is the A/AAAA record
▼
[ Recursive Resolver ] (cache result)
│
▼
[ Browser connects to IP ]
3. Recursive resolver interaction with name servers
┌───────────┐
│ Browser │
└─────┬─────┘
│ DNS query
▼
┌────────────────────┐
│ Recursive Resolver │
│ (Caching Layer) │
└───────┬────────────┘
│
┌───────┴────────┐
│ │
Cache HIT Cache MISS
│ │
▼ ▼
Fast response Root → TLD → Auth
Name Servers
4. Mapping dig commands to DNS lookup stages
User runs: dig . NS
│
▼
Root Name Servers
User runs: dig com NS
│
▼
TLD Name Servers (.com)
User runs: dig google.com NS
│
▼
Authoritative Servers (Google)
User runs: dig google.com
│
▼
Final Answer: A / AAAA record (IP)
Final Mental Model
DNS is hierarchical and delegated
Each layer only knows the next hop
diglets you inspect each layer explicitlyRecursive resolvers hide complexity for clients
If you understand DNS, you understand one of the most important distributed systems ever built.
Happy digging.