How DNS Resolution Works
Let’s begin with a story.
Imagine you want to visit your friend Raju’s house.
You know his name: Raju
But you don’t know his house number.
So you ask:
“Where does Raju live?”
Someone gives you the address.
Now you can reach his house.
That is exactly what happens on the internet.
You know:
google.com
But computers need:
142.250.192.14
The process of finding the real address from the name is called:
DNS Resolution
🧠 What is DNS and Why Name Resolution Exists
Computers talk using numbers (IP addresses).
Humans talk using names (domain names).
So we need a translator between humans and computers.
That translator is DNS (Domain Name System).
DNS does:
google.com → 142.250.192.14
The process of converting name → number is called:
Name Resolution
Without name resolution:
No websites
No apps
No emails
No internet as we know it
📖 DNS is the Internet’s Phonebook
Think of DNS as a giant phonebook.
You search:
DNS gives:
Its phone number (IP)
But here’s the twist…
This phonebook is not stored in one place.
It is distributed across the entire world.
🌳 DNS Works Like a Tree (Hierarchy)
DNS is organized like a family tree:
. (Root)
└── com
└── google.com
└── www.google.com
There are three big levels:
Root servers
TLD servers (.com, .org, .in)
Authoritative servers (real owner of domain)
We’ll use this structure again when we learn dig.
🛠️ What is the dig Command?
Now meet a very powerful tool.
dig = Domain Information Groper
But don’t worry about the name.
dig is simply:
A tool that lets you ask DNS questions directly.
Instead of:
“Browser, find IP for me”
You say:
“Hey DNS, tell me the IP for this domain.”
Example:
dig google.com
Now you are directly talking to the DNS system.
This is why developers use dig:
Debug DNS problems
Understand resolution
Learn how internet works
Inspect name servers
Act like a DNS detective 🕵️
🧒 Let’s Start Simple: dig google.com
Run:
dig google.com
You’ll see an answer section like:
google.com. 300 IN A 142.250.192.14
That means:
Domain: google.com
Type: A record
IP: 142.250.192.14
TTL: 300 seconds
Congratulations.
You just manually performed DNS lookup like a professional.
🌐 Understanding Root Name Servers (dig . NS)
Let’s ask:
dig . NS
You are asking:
Who controls the root of the internet?
You’ll see servers like:
a.root-servers.net
b.root-servers.net
...
m.root-servers.net
These are the root DNS servers.
They are like:
The grandparents of the entire internet.
They don’t know everything.
But they know:
Who manages .com, .org, .in, etc.
🏙️ Understanding TLD Servers (dig com NS)
Now ask:
dig com NS
You are saying:
Who controls all .com domains?
You’ll see name servers that manage the .com zone.
These servers don’t know where google.com lives.
But they know:
Which authoritative servers control google.com.
🏠 Understanding Authoritative Servers (dig google.com NS)
Now run:
dig google.com NS
You are asking:
Who are Google’s official DNS servers?
You’ll see:
ns1.google.com
ns2.google.com
...
These are the servers that hold the real DNS records like:
A
AAAA
MX
TXT
CNAME
This is where truth lives.
🧠 Now the Full DNS Resolution Flow Using dig
Let’s simulate how the internet really resolves google.com.
Step 1: Ask Root
Root says:
Ask .com servers
Step 2: Ask .com servers
They say:
Ask Google’s name servers
Step 3: Ask Google’s authoritative server
They finally say:
Here is the IP: 142.250.192.14
This is exactly what happens behind the scenes when:
Browser loads
App loads
API works
Anything connects to a domain
🔁 Recursive Resolver: The Hidden Helper
You might wonder:
Do we manually ask root, TLD, authoritative every time?
No.
There is a helper called:
Recursive Resolver
This is usually:
Your ISP DNS
Google DNS (8.8.8.8)
Cloudflare DNS (1.1.1.1)
Its job:
Ask root
Ask TLD
Ask authoritative
Cache answers
Reply to you quickly
So when you type a website, your system says:
“Hey resolver, you handle the DNS headache for me.”
🧪 How dig Connects to Real Browser Behavior
When you run:
dig google.com
You are basically doing:
What your browser does before opening any website.
Browser:
Ask resolver
Resolver asks root
Then TLD
Then authoritative
Gets IP
Browser connects to IP
dig just lets you see the invisible process.
🧱 Mapping dig Commands to DNS Layers
| Command | What you're asking |
| dig . NS | Who controls root? |
| dig com NS | Who controls .com? |
| dig google.com NS | Who controls google.com? |
| dig google.com | What is the IP of google.com? |
You are literally walking through the architecture of the internet.
📌 Why NS Records Matter So Much
NS records decide:
Who has control over a domain.
If NS records are wrong:
Website breaks
Email breaks
SSL breaks
Everything breaks
When you buy domain + hosting:
Domain provider controls NS
You point NS to hosting provider
Hosting provider becomes DNS authority
That’s real-world DNS ownership.
🧠 Advanced View: System Design Perspective
Big companies use DNS like infrastructure:
Multiple authoritative servers
Geo-distributed name servers
Anycast routing
Recursive caching
Low TTL for failover
Smart routing
DDoS-resistant architecture
DNS is not just lookup.
DNS is part of system reliability engineering.
🎯 Why Understanding This Makes You Powerful
Most developers:
Use domains
Configure hosting
Copy DNS settings
But don’t understand it
You now understand:
Why dig works
How root works
How TLD works
How authoritative servers work
How resolvers work
How browser actually resolves domains
That’s real internet knowledge.
❤️ Final Words
DNS resolution sounds complex.
But in reality, it is just:
Asking the right people the right questions in the right order.
Root → TLD → Authoritative → IP
You didn’t just learn commands.
You learned the architecture of global internet communication.