Understanding DNS Resolution Using dig (Without Overthinking)
I write technical articles for developers who already know the basics but want clarity. No hand-holding, no fluff — just structured explanations for people revisiting concepts or fixing confusion.
Before jumping into commands, quick basics.
What is DNS and why name resolution exists
DNS is the phonebook of the internet.
Humans like names (google.com), machines like numbers (IP addresses).
Name resolution exists because remembering IPs is painful, and DNS quietly handles the mapping for us every single time we open a website.
What is dig and when it is used
dig stands for Domain Information Groper (weird name, useful tool).
It’s a command-line tool used to inspect how DNS resolution actually happens.
Developers use it when:
debugging DNS issues
checking name servers
understanding where a domain is resolved from
Basically, dig lets you see what DNS is doing behind the scenes.
DNS resolution happens in layers
DNS works like a hierarchy:
Root → TLD → Authoritative
Your system (or browser) doesn’t magically know the IP. It walks through these layers step by step, usually via a recursive resolver.
dig . NS — Root name servers
Command:
dig . NS
This asks: “Who is responsible for the root of DNS?”
The output shows root name servers.
These servers don’t know IPs of websites — they only know where to go next.
Think of them as the top-level directory of the internet.
dig com NS — TLD name servers
Command:
dig com NS
Now we’re asking: “Who manages the .com domains?”
These TLD name servers handle all .com, .org, .net, etc.
They still don’t know google.com’s IP, but they know which authoritative servers do.
dig google.com NS — Authoritative name servers
Command:
dig google.com NS
This shows the authoritative name servers for google.com.
These servers are important because:
they store the actual DNS records
they give final answers (A, AAAA, etc)
This is where truth lives for the domain.
dig google.com — Full DNS resolution
Command:
dig google.com
This is the final step.
Here you get:
IP addresses (A / AAAA records)
the answer your browser actually needs
Behind the scenes, a recursive resolver already talked to:
root servers
TLD servers
authoritative servers
and then returned the result to you.
Why NS records matter
NS records define who is responsible at every level:
root NS → top of DNS
TLD NS → domain category
authoritative NS → actual domain data
Without NS records, DNS resolution breaks completely.
How this connects to real browser requests
When you type google.com in a browser:
browser asks OS
OS asks recursive resolver
resolver walks the DNS hierarchy
IP comes back
browser connects to server
dig just lets you observe this process manually.
Why this matters (system design angle)
Understanding DNS helps you:
debug production issues
design reliable systems
reason about latency and failures
not panic when “site not loading”
DNS feels invisible, but it’s one of the most critical systems on the internet.