Understanding DNS Resolution using dig
DNS – the internet’s phonebook 📖
Computers do not understand names like google.com.
They only understand IP addresses.
Humans, on the other hand, cannot remember IPs easily.
So we needed a system that could answer one simple question:
“If I give you a domain name, where exactly is it located?”
That system is called DNS (Domain Name System).
DNS works like the internet’s phonebook:
Name → IP address
google.com→ some numeric address
This process is called name resolution.
Why do we need to inspect DNS resolution?
When you open a website in a browser, DNS resolution happens silently in the background.
You never see:
which server was asked
who replied
where the information came from
As developers and system designers, we should not trust magic.
That’s why we use dig.
What is dig and why use it?
dig (Domain Information Groper) is a DNS diagnostic tool.
In simple words:
digallows us to ask DNS questions and see exactly who answers what.
Browsers hide DNS.dig exposes it.
Think of it as:
cURL for DNS
DNS resolution happens in layers (very important)
DNS is not one big server.
It works in layers, so the internet can scale:
Root DNS
↓
TLD DNS (.com, .org, .in)
↓
Authoritative DNS (domain owner)
Each layer answers only one type of question.
Step 1: Root name servers (dig . NS)
dig . NS
This command asks:
“Who are the root name servers of the internet?”
Root servers do not know anything about google.com.
Their only job:
“I know who handles
.com,.org,.net, etc.”
They are the starting point of every DNS lookup.
Step 2: TLD name servers (dig com NS)
dig com NS
This asks:
“Who is responsible for the
.comdomain?”
These servers are called TLD (Top Level Domain) servers.
They do not know IP addresses either.
Their job:
“For
google.com, ask these authoritative servers.”
Step 3: Authoritative name servers (dig google.com NS)
dig google.com NS
This asks:
“Who is authoritative for google.com?”
The response contains NS records.
What do NS records mean?
An NS record answers one question:
“Which DNS servers are allowed to give final answers for this domain?”
Example (simplified):
google.com → ns1.google.com
This is critical because:
DNS must be trustworthy
Only the domain owner should give final answers
Without NS records:
DNS would not know whom to trust
Domain resolution would fail
Step 4: Final resolution (dig google.com)
dig google.com
This gives the final answer — usually an A record (IP address).
But behind the scenes, this is what really happened 👇
Step-by-step DNS resolution flow (diagram)
Client (Browser / dig)
|
| 1. "Who handles .com?"
v
Root DNS Server
|
| 2. ".com is handled by these servers"
v
TLD DNS Server (.com)
|
| 3. "google.com is handled by Google DNS"
v
Authoritative DNS (Google)
|
| 4. "Here is the IP address"
v
Client connects to server
All of this happens in milliseconds.
Where does the recursive resolver fit?
Your browser does not talk to root servers directly.
Instead, it asks a recursive resolver:
ISP DNS
Google DNS (8.8.8.8)
Cloudflare DNS (1.1.1.1)
The resolver:
Performs the full root → TLD → authoritative journey
Caches results
Returns the final answer to your browser
This is why DNS feels fast even though it involves multiple steps.
Connecting dig google.com to real browsers
When you type:
https://google.com
Your browser:
Asks recursive resolver
Resolver performs DNS resolution
Gets IP address
Browser connects to server
Website loads
dig google.com simply lets you observe step 3 clearly.
Why this matters for system design
Understanding DNS helps you:
Debug production issues
Design scalable systems
Understand CDNs
Handle failover correctly
Avoid blind trust in “it just works”
DNS is not magic.
It is well-designed distributed system engineering.
Final thoughts
DNS exists to translate names into addresses, but its real power lies in how it distributes responsibility across the internet.
Using dig, we can peel back the layers and see:
who controls what
how trust is established
how browsers actually reach servers
Once DNS clicks, many networking and system-design concepts become much clearer.
