When you type google.com into your browser and press Enter, you’re not actually connecting to “google.com”.
You’re connecting to an IP address like 142.250.77.46.
So the real question is:
How does the internet convert human-friendly names into machine-friendly IPs?
That system is called DNS (Domain Name System) often described as the internet’s phonebook.
This article walks step-by-step through:
- What DNS is and why it exists
- How the
digcommand helps us inspect DNS - Root, TLD, and authoritative name servers
- The full DNS resolution flow for
google.com - How all of this connects to real browser requests
And we’ll build everything logically using real dig commands.
What is DNS and why name resolution exists
Computers don’t understand domain names.
They communicate using IP addresses.
But humans don’t want to remember this: 142.250.77.46
So DNS exists to answer one simple question:
“What is the IP address of this domain name?”
Example: google.com → 142.250.77.46
DNS provides:
- Human-readable names
- Decentralized global database
- Scalable and fault-tolerant name resolution
Without DNS, the modern web wouldn’t be usable.
What is the dig command and when it is used
dig (Domain Information Groper) is a DNS diagnostic tool.
It allows you to:
- Query DNS servers directly
- Inspect DNS records (A, NS, MX, TXT, etc.)
- Debug DNS issues
- Understand how name resolution actually works
Example:
dig google.com
This doesn’t just give you an IP, it shows the entire DNS answer structure.
DNS works in layers
DNS is hierarchical
Each layer doesn’t know the final answer.
It only knows who to ask next.
Understanding dig . NS → Root name servers
Let’s start at the very top.
dig . NS
This asks:
“Who are the name servers for the root of DNS?”
You’ll see servers like:
a.root-servers.net
b.root-servers.net
c.root-servers.net
...
These are root name servers.
They do NOT know the IP of google.com.
They only know:
“Who manages .com?”
“Who manages .org?”
Their job is to point you to TLD name servers.
Understanding dig com NS → TLD name servers
Now let’s move one level down.
dig com NS
This asks:
“Who manages the .com domain?”
The response returns name servers operated by companies like Verisign.
These TLD servers don’t know Google’s IP either.
They only know:
“Who is authoritative for google.com?”
So they return the authoritative name servers for google.com.
Understanding dig google.com NS → Authoritative name servers
dig google.com NS
This returns servers like:
ns1.google.com
ns2.google.com
ns3.google.com
ns4.google.com
These are authoritative name servers.
This is where truth lives.
They store the real DNS records:
- A (IP address)
- MX (mail servers)
- TXT (verification, SPF, etc.)
If you want the actual IP of google.com, this is where it comes from.
Understanding dig google.com → Full DNS resolution
dig google.com
You’ll see something like:
google.com. 300 IN A 142.250.77.46
Behind the scenes (if uncached), the resolver performed:
- Ask root → who handles .com?
- Ask TLD → who handles google.com?
- Ask authoritative → what is the IP?
Your system’s recursive resolver did all this work for you.
What NS records really represent
NS records don’t map names to IPs.
They map names to name servers responsible for that zone.
Example:
google.com → ns1.google.com
They define ownership and delegation.
This is how DNS stays:
- Decentralized
- Scalable
- Company-controlled
Google controls its DNS.
You control yours.
The root doesn’t control Google.
What your recursive resolver actually does
Your computer usually talks to:
- ISP DNS
- Router DNS
- Public DNS (8.8.8.8, 1.1.1.1)
These are recursive resolvers.
They You ask one question:
- Query root servers
- Query TLD servers
- Query authoritative servers
- Cache results
- Protect you from complexity
They perform the entire DNS walk.
How this connects to real browser requests
When you visit:
https://www.google.com
Your browser:
- Asks OS for IP
- OS asks recursive resolver
- Resolver walks DNS
- Gets IP
- Browser opens TCP connection
- TLS handshake starts
- HTTP request is sent

No DNS = No website.
Every API call, cloud service, CDN, and microservice starts with DNS.
Mapping dig to DNS lookup stages
| Command | What it represents |
| ----------------- | --------------------- |
| dig . NS | Root name servers |
| dig com NS | TLD name servers |
| dig google.com NS | Authoritative servers |
| dig google.com | Final resolution |
Top comments (0)