How DNS Resolution Works
If you use the internet, you use DNS — even if you never heard of it before.
When you type google.com in your browser, something in the background has to figure out:
“What IP address is google.com?”
That “something” is the DNS system, and dig is a tool that lets you see what is going on under the hood.
In this article, we will look at:
What DNS is and why name resolution exists
What the dig command is and when it is used
How DNS resolution happens in layers: root → TLD → authoritative
How dig. NS, dig com NS, dig google.com, and dig google.com all connect
Language will stay simple and practical. Think of this as a gentle networking lesson for beginners who want to understand how the internet actualy works.
1. What is DNS? (The Internet’s Phonebook)
1.1 Humans like names, computers like numbers
Humans like names: google.com, facebook.com, myblog.dev.
Computers use IP addresses: 142.250.72.14 or 2404:6800:4004:81b::200e.
Remembering all these IPs would be painful and impossible. So we use DNS – Domain Name System.
DNS is like a huge distributed phonebook for the internet:
You: “What is the IP address of google.com?”
DNS: “Here you go: 142.250.72.14” (example).
This process of turning a name (like google.com) into an IP address is called name resolution.
1.2 Why does name resolution exist?
Name resolution exists because:
Humans think in names, not numbers.
Websites can change servers or IP addresses in the background.
DNS lets us keep a stable domain name while changing the underlying infrastructure.
This extra layer also helps with:
Load balancing: many IPs for one domain.
High availability: switch IPs if a server is down.
Geo-routing: show a different IP (closer server) depending on where the user is.
So DNS is not just a phonebook. It is also a smart routing and abstraction layer for the internet.
2. What is dig, and when is it used?
dig means Domain Information Groper. Yes, the name is a bit strange. But it’s very useful.
2.1 What dig does
dig is a command-line tool that asks questions to DNS servers. For example:
dig google.com
This command sends a DNS query and shows:
What you asked
What answer came back
Which records and servers were involved
With dig, you can ask things like:
“What is the IP address of google.com?”
“Which name servers are responsible for com?”
“Which name servers are authoritative for shivam-goyal.site?”
2.2 When you use dig (in real life)
You use dig when you:
- Debug DNS problems
“My domain is not working, why?”
- Check DNS propagation
“I changed a record – did the internet see it yet?”
- Learn how DNS works
See each step of the resolution process.
- Do system design / DevOps / backend work
DNS is part of almost every non-trivial system.
If you are serious about backend, cloud, or DevOps, knowing dig is almost like knowing curl for HTTP.
3. DNS Hierarchy: Root → TLD → Authoritative
Before we start playing with dig, we need to understand the DNS hierarchy.
Think of DNS like a big tree:
Root (.) – at the very top.
TLDs (Top-Level Domains) – .com, .org, .net, .io, .in, etc.
Domains – google.com, example.com, myblog.io.
Subdomains – www.google.com, api.myblog.io, etc.
3.1 Who knows what?
- Root servers:
Know which servers handle each TLD (like .com, .org).
- TLD servers (for .com):
Know which servers handle each domain under .com (like google.com, facebook.com).
- Authoritative servers (for google.com):
Know the actual records for that domain (IP addresses, mail servers, etc).
Your recursive resolver (usually your ISP DNS or something like 8.8.8.8 or 1.1.1.1) walks this tree to find answers.
4. dig. NS – Root Name Servers
Now let’s map commands to layers, starting from the top.
4.1 What dig. NS means
dig. NS
. → the root zone (top of the DNS hierarchy)
NS → Name Server record type
You are basically asking:
“Which name servers are responsible for the root of the DNS system?”
4.2 What you will see (conceptually)
You will see root servers like:
a.root-servers.net
b.root-servers.net
…
m.root-servers.net
There are 13 logical root name servers (A to M), but each one is actually a large cluster of machines across the world.
4.3 Why root name servers matter
They are the first step when nothing is cached.
They do not know the IP of google.com.
They do know which name servers handle .com, .org, .net, etc.
They basically say:
“I don’t know google.com, but here is who knows about .com. Go ask them.”
5. dig com NS – TLD Name Servers
Now we move one level down: the TLD (Top-Level Domain).
5.1 What does dig com NS means
dig com NS
This means:
“Which name servers are responsible for the .com TLD?”
5.2 What you will see
You will see something like:
a.gtld-servers.net
b.gtld-servers.net
…
m.gtld-servers.net
These are TLD name servers for .com.
5.3 What TLD servers do
TLD servers for .com don’t know all the IPs, but they know:
“For google.com, these are the authoritative name servers.”
“For facebook.com, these other servers are authoritative.”
So for our google.com question, a .com TLD server basically says:
“I don’t know the IP of google.com, but I know which servers are authoritative for google.com. Ask them.”
6. dig google.com NS – Authoritative Name Servers
Now we reach the domain itself.
6.1 What dig google.com NS means
dig google.com NS
This means:
“Which name servers are authoritative for google.com?”
6.2 What you will see
Something like:
ns1.google.com
ns2.google.com
ns3.google.com
ns4.google.com
(Names and numbers may differ, but the idea is the same.)
These are authoritative name servers for the google.com zone.
6.3 What authoritative servers do
Authoritative servers are the source of truth for a domain. They know:
A / AAAA records – IP addresses for google.com, www.google.com, etc.
MX records – mail servers.
TXT records – SPF, verification, etc.
CNAME records – aliases, and more.
So when they get the question:
\> “What is the IP address (A record) for google.com?”
They can answer directly, for example:
\> “A record for google.com is 142.250.72.14” (example IP, may change in reality).
From a system design point of view, this is where your DNS configuration for your domain lives (often in a DNS provider or cloud panel).
7. dig google.com – The Full DNS Resolution Flow
Now the most common thing you do with dig.
7.1 What does dig google.com does
dig google.com
By default, this asks your configured recursive resolver (like 8.8.8.8, 1.1.1.1, or your ISP resolver):
It checks its cache first.
If not cached, it does the full walk:
Ask a root server: “Who handles .com?”
Ask a .com TLD server: “Who handles google.com?”
Ask a google.com authoritative server: “What is the A record for google.com?”
- It returns the final answer to dig.
dig then shows you:
QUESTION SECTION – What you asked.
ANSWER SECTION – The IP addresses or records you got.
Maybe AUTHORITY / ADDITIONAL sections – extra data about name servers and helper records.
7.2 Why you don’t always see every hop
In a simple dig google.com, you usually don’t see each step (root, .com, etc.) because:
Your recursive resolver hides this work.
Many answers may already be in cache.
But the logical steps still exist behind the scenes. To see all hops in detail, you can later try:
dig +trace google.com
This walks and prints every step (root → TLD → authoritative).
8. How Recursive Resolvers Use These Layers
Let’s imagine nothing is cached, and you ask for google.com.
8.1 Step-by-step flow
Browser: “I need https://google.com.”
Operating System: “I need the IP for google.com.”
Recursive Resolver (DNS server you configured):
Step 1 – Ask Root
“Who knows about .com?”
Root replies with NS records for .com TLD servers.
Step 2 – Ask .com TLD
“Who knows about google.com?”
TLD replies with NS records for google.com authoritative servers.
Step 3 – Ask google.com authoritative information
“What is the A record for google.com?”
The authoritative server replies with the IP address.
Step 4 – Cache results
Resolver stores these results for some time (TTL – Time To Live) to answer future queries faster.
Resolver returns the IP to your OS, which gives it to your browser.
Browser now opens a TCP/TLS connection to this IP and starts the HTTP / HTTPS request.
8.2 Mapping this to dig commands
Each dig command is like zooming in on one step:
dig. NS → Root layer – who knows the TLDs.
dig com NS → TLD layer – who knows google.com.
dig google.com NS → Authoritative layer – who knows the records for google.com.
dig google.com → Final answer – what the user actually needs (IP)
This mapping is very helpful when you learn system design or need to debug weird DNS issues.
9. How This Relates To Real Browser Requests
Every time you visit a website:
Before your browser sends HTTP/HTTPS traffic…
It usually does a DNS lookup first (unless already cached).
So:
Performance: Slow DNS = web page feels slow, even before anything loads.
Reliability: DNS misconfiguration = site seems “down” even if servers are fine.
Routing & scaling:
CDNs use DNS to send you to the nearest edge.
Multi-region apps use DNS to split traffic.
Failover strategies often update DNS records.
Knowing a bit of dig and DNS puts you in a much better position to design, debug, and scale systems.
10. Quick Recap
DNS is the Internet’s phonebook, mapping domain names to IP addresses.
Name resolution exists because humans like names, machines need IPs, and we want flexibility and indirection.
dig is a simple but powerful DNS diagnostic tool.
DNS is structured in layers:
Root: dig. NS
TLD (.com): dig com NS
Authoritative (google.com): dig google.com NS
Final answer (A/AAAA): dig google.com
Recursive resolvers walk through these layers for you, cache answers, and serve your apps and browsers behind the scenes.
Understanding this flow is very useful for system design, DevOps, backend, and debugging real-world issues.
If you want to practice, open a terminal and try in this order:
dig. NS
dig com NS
dig google.com NSdig google.com
Happy Learning! 🚀
Have questions about how browsers work? Drop them in the comments!
