How DNS Resolution Works

Understanding DNS Using dig (Beginner Notes)

When I first started learning how the internet actually works, DNS felt like magic. I could type google.com in my browser and somehow it knew where to go. Recently, I decided to finally understand how that name becomes an IP address, and this is what I learned.

This blog is basically my notes while learning DNS, written in a way that might help other beginners too.

What is DNS and Why Name Resolution Exists

DNS (Domain Name System) is often called the internet’s phonebook, and honestly, that analogy helped me a lot.

Computers don’t understand names like google.com. They only understand IP addresses like 142.250.183.14. But humans are bad at remembering numbers, so DNS exists to translate human-friendly names → machine-friendly IPs.

So when you type a website name:

google.com

DNS helps figure out:

Which server (IP address) should I talk to?

This translation process is called name resolution.

What is the dig Command and When It Is Used

While learning DNS, I came across a tool called dig (Domain Information Groper).

From what I understand, dig is mainly used to:

1. Inspect DNS records

2. Debug DNS issues

3. See how DNS resolution actually works step by step

Browsers hide all this complexity, but dig shows what’s happening behind the scenes.

dig google.com

This command asks:

“Hey DNS, can you give me information about google.com?”

Understanding dig . NS and Root Name Servers

This part confused me at first.

When I ran:

dig . NS

I learned that the . (dot) represents the DNS root.

Root name servers are at the top of the DNS hierarchy. They don’t know IP addresses of websites, but they know where to find the next level.

The output shows servers like:

a.root-servers.net
b.root-servers.net
...

So basically:

• Root servers don’t resolve domains

• They tell you which TLD name servers to ask next

This is the first step in DNS resolution.

Understanding dig com NS and TLD Name Servers

Next, I tried:

dig com NS

Here, com is a Top-Level Domain (TLD).

TLD name servers are responsible for domains ending in .com, .org, .net, etc.

What I learned:

• Root → points to TLD servers

• TLD servers → know where authoritative servers live

So .com name servers don’t know Google’s IP either, but they know who is responsible for google.com.

Understanding dig google.com NS and Authoritative Name Servers

Then I ran:

dig google.com NS

This finally showed:

ns1.google.com
ns2.google.com
...

These are authoritative name servers.

Important thing I learned:

• Authoritative servers are the source of truth

• They store actual DNS records like A, AAAA, MX, etc.

So if you want the real IP address of google.com, these are the servers that can give it.

Understanding dig google.com and the Full DNS Resolution Flow

Finally:
dig google.com

This returns the A record, which contains the IP address.

What surprised me is that my system usually talks to a recursive resolver (like my ISP or Google DNS), not directly to root servers.

Behind the scenes, the resolver does this:

1. Ask root servers → “Where is .com?”

2. Ask .com servers → “Where is google.com?”

3. Ask Google’s authoritative servers → “What is the IP?”

4. Cache the answer

5. Return it to my browser

All of this happens in milliseconds.

Why NS Records Matter

NS (Name Server) records tell the DNS system:

“These servers are responsible for this domain.”

Without NS records:

• DNS delegation wouldn’t work

• The hierarchy would break

• The internet would basically stop resolving names

They are like signboards that tell resolvers where to go next.

How This Connects to Real Browsers

When you type google.com in your browser:

• The browser asks the OS

• The OS asks a recursive resolver

• The resolver uses the DNS hierarchy (root → TLD → authoritative)

• The IP comes back

• The browser finally makes an HTTP/HTTPS request

DNS is the first step before any web request happens.