DNS Resolution with dig Tool

DNS – the internet’s phonebook 📖

Computers do not understand names like google.com.
They only understand IP addresses.

Humans, on the other hand, cannot remember IPs easily.
So we needed a system that could answer one simple question:

“If I give you a domain name, where exactly is it located?”

That system is called DNS (Domain Name System).

DNS works like the internet’s phonebook:

Name → IP address
google.com → some numeric address

This process is called name resolution.

Why do we need to inspect DNS resolution?

When you open a website in a browser, DNS resolution happens silently in the background.
You never see:

which server was asked
who replied
where the information came from

As developers and system designers, we should not trust magic.

That’s why we use dig.

What is `dig` and why use it?

dig (Domain Information Groper) is a DNS diagnostic tool.

In simple words:

dig allows us to ask DNS questions and see exactly who answers what.

Browsers hide DNS.
dig exposes it.

Think of it as:

cURL for DNS

DNS resolution happens in layers (very important)

DNS is not one big server.

It works in layers, so the internet can scale:

Root DNS
   ↓
TLD DNS (.com, .org, .in)
   ↓
Authoritative DNS (domain owner)

Each layer answers only one type of question.

Step 1: Root name servers (`dig . NS`)

dig . NS

This command asks:

“Who are the root name servers of the internet?”

Root servers do not know anything about google.com.

Their only job:

“I know who handles .com, .org, .net, etc.”

They are the starting point of every DNS lookup.

Step 2: TLD name servers (`dig com NS`)

dig com NS

This asks:

“Who is responsible for the .com domain?”

These servers are called TLD (Top Level Domain) servers.

They do not know IP addresses either.

Their job:

“For google.com, ask these authoritative servers.”

Step 3: Authoritative name servers (`dig` `google.com` `NS`)

dig google.com NS

This asks:

“Who is authoritative for google.com?”

The response contains NS records.

What do NS records mean?

An NS record answers one question:

“Which DNS servers are allowed to give final answers for this domain?”

Example (simplified):

google.com → ns1.google.com

This is critical because:

DNS must be trustworthy
Only the domain owner should give final answers

Without NS records:

DNS would not know whom to trust
Domain resolution would fail

Step 4: Final resolution (`dig` `google.com`)

dig google.com

This gives the final answer — usually an A record (IP address).

But behind the scenes, this is what really happened 👇

Step-by-step DNS resolution flow (diagram)

Client (Browser / dig)
        |
        | 1. "Who handles .com?"
        v
Root DNS Server
        |
        | 2. ".com is handled by these servers"
        v
TLD DNS Server (.com)
        |
        | 3. "google.com is handled by Google DNS"
        v
Authoritative DNS (Google)
        |
        | 4. "Here is the IP address"
        v
Client connects to server

All of this happens in milliseconds.

Where does the recursive resolver fit?

Your browser does not talk to root servers directly.

Instead, it asks a recursive resolver:

ISP DNS
Google DNS (8.8.8.8)
Cloudflare DNS (1.1.1.1)

The resolver:

Performs the full root → TLD → authoritative journey
Caches results
Returns the final answer to your browser

This is why DNS feels fast even though it involves multiple steps.

Connecting `dig` `google.com` to real browsers

When you type:

https://google.com

Your browser:

Asks recursive resolver
Resolver performs DNS resolution
Gets IP address
Browser connects to server
Website loads

dig google.com simply lets you observe step 3 clearly.

Why this matters for system design

Understanding DNS helps you:

Debug production issues
Design scalable systems
Understand CDNs
Handle failover correctly
Avoid blind trust in “it just works”

DNS is not magic.
It is well-designed distributed system engineering.

Final thoughts

DNS exists to translate names into addresses, but its real power lies in how it distributes responsibility across the internet.

Using dig, we can peel back the layers and see:

who controls what
how trust is established
how browsers actually reach servers

Once DNS clicks, many networking and system-design concepts become much clearer.

Understanding DNS Resolution using dig

Comments

More from this blog

How Instagram Stores Reels, Photos, and Drafts Behind the Scenes

How WhatsApp Works Without Internet: Offline Messaging and Sync Explained

Expo Router vs React Navigation - Which One Should You Use in 2026?

How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router

How React Virtual DOM works under the hood

DNS – the internet’s phonebook 📖

Why do we need to inspect DNS resolution?

What is `dig` and why use it?

DNS resolution happens in layers (very important)

Step 1: Root name servers (`dig . NS`)

Step 2: TLD name servers (`dig com NS`)

Step 3: Authoritative name servers (`dig` `google.com` `NS`)

What do NS records mean?

Step 4: Final resolution (`dig` `google.com`)

Step-by-step DNS resolution flow (diagram)

Where does the recursive resolver fit?

Connecting `dig` `google.com` to real browsers

Why this matters for system design

Final thoughts

Command Palette

Comments

More from this blog

DNS – the internet’s phonebook 📖

Why do we need to inspect DNS resolution?

What is dig and why use it?

DNS resolution happens in layers (very important)

Step 1: Root name servers (dig . NS)

Step 2: TLD name servers (dig com NS)

Step 3: Authoritative name servers (dig google.com NS)

What do NS records mean?

Step 4: Final resolution (dig google.com)

Step-by-step DNS resolution flow (diagram)

Where does the recursive resolver fit?

Connecting dig google.com to real browsers

Why this matters for system design

Final thoughts

What is `dig` and why use it?

Step 1: Root name servers (`dig . NS`)

Step 2: TLD name servers (`dig com NS`)

Step 3: Authoritative name servers (`dig` `google.com` `NS`)

Step 4: Final resolution (`dig` `google.com`)

Connecting `dig` `google.com` to real browsers