DNS Explained with dig: How Your Browser Finds Google.com

DNS: The Internet’s Phonebook

Imagine if every time you wanted to call a friend, you had to remember their phone number instead of their name.

That’s exactly how the internet works.

• Computers talk using IP addresses (like 142.250.190.14)

• Humans prefer names (like google.com)

DNS (Domain Name System) exists to convert names → IP addresses
That process is called name resolution.

Without DNS, the internet would be unusable for humans.

Why Name Resolution Exists

• IP addresses are hard to remember

• IPs can change, names usually don’t

• DNS allows flexibility, scalability, and reliability

So when you type:

https://google.com

Your browser asks:

“What is the IP address of google.com?”

DNS answers that question.

Introducing dig: A DNS X-Ray Tool

dig stands for Domain Information Groper.

Think of dig as:

“Show me how DNS is answering this question”

It’s mainly used by:

• Developers

• System designers

• DevOps / SREs

• Network engineers

Instead of guessing what DNS is doing, dig lets you see it.

DNS Resolution Happens in Layers

DNS is hierarchical, not flat.

The resolution happens in this order:

Root servers
   ↓
TLD servers (.com, .org, .in)
   ↓
Authoritative servers (google.com)

Let’s walk through this layer by layer using dig.

1) dig . NS → Root Name Servers

dig . NS

What does this mean?

• . (dot) represents the root of DNS

• NS asks: “Who are the name servers?”

What you learn

This command shows the root name servers of the internet.

These servers:

• Don’t know IPs of websites

• Only know who handles .com, .org, .net, etc.

Think of them as:

“I don’t know Google, but I know who manages .com.”

This is the starting point of every DNS lookup.

2) dig com NS → TLD Name Servers

dig com NS

What does this mean?

You’re asking:

“Who manages domains that end with .com?”

What you learn

The response lists TLD (Top-Level Domain) servers for .com.

Their job:

• They don’t know IP addresses either

• They know which authoritative servers manage google.com

Think of them as:

“For google.com, talk to these servers.”

3) dig google.com NS → Authoritative Name Servers

dig google.com NS

What does this mean?

Now you’re asking:

“Who is officially responsible for google.com?”

What you learn

These are authoritative name servers.

They:

• Are controlled by Google

• Store the real DNS records

• Give the final, trusted answers

This is where truth lives in DNS.

Why NS Records Matter

NS (Name Server) records answer one simple question:
“Who should I ask next?”

They:

• Enable DNS delegation

• Make DNS scalable

• Allow distributed ownership

Without NS records:

• DNS would be centralized

• The internet wouldn’t scale

---

4) dig google.com → Full DNS Resolution

dig google.com

What happens here?

You’re asking:

“Give me the IP address for google.com”

Behind the scenes (important!)

Even though you run one command, your recursive resolver does this:

1. Ask root server → who handles .com?

2. Ask .com TLD server → who handles google.com?

3. Ask authoritative server → what is the IP?

4. Cache the answer

5. Return the IP to your browser

All this happens in milliseconds.

Recursive Resolvers: The Hidden Workers

Your browser doesn’t talk to root servers directly.

Instead, it asks a recursive resolver, usually provided by:

• Your ISP

• Google DNS (8.8.8.8)

• Cloudflare (1.1.1.1)

The resolver:

• Walks the DNS tree

• Follows NS records

• Caches results for performance

This is why websites load fast after the first visit.

Connecting DNS to Real Browser Requests

When you type google.com:

1. Browser needs IP

2. DNS resolves name → IP

3. Browser opens TCP connection

4. TLS handshake happens

5. HTTP request is sent

6. Google responds

DNS is always step zero

If DNS fails:

• Website doesn’t load

• App breaks

• APIs fail

That’s why DNS is critical infrastructure.

System Design Perspective

DNS is a perfect example of:

• Distributed systems

• Caching

• Delegation

• Fault tolerance

Key takeaways:

• No single point of failure

• Clear separation of responsibility

• Massive scalability

This is why DNS has survived for decades.

Final Mental Model

Think of DNS like this:

Root:      "I know who manages .com"
TLD:       "I know who manages google.com"
Auth:      "Here is the IP address"
Resolver:  "I’ll do the walking for you"
Browser:   "Cool, let’s load the site"

Closing Thoughts

If you understand:

• dig . NS

• dig com NS

• dig google.com NS

• dig google.com

You understand how the internet finds anything.