# Understanding DNS Resolution using dig

## DNS – the internet’s phonebook 📖

Computers do not understand names like [`google.com`](http://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`](http://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:

```coffeescript
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`)

```coffeescript
dig . NS
```

This command asks:

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

Root servers do **not** know anything about [`google.com`](http://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`)

```coffeescript
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`](http://google.com), ask these authoritative servers.”

---

## Step 3: Authoritative name servers (`dig` [`google.com`](http://google.com) `NS`)

```coffeescript
dig google.com NS
```

This asks:

> “Who is authoritative for [google.com](http://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):

```coffeescript
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`](http://google.com))

```coffeescript
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)

```coffeescript
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`](http://google.com) to real browsers

When you type:

```coffeescript
https://google.com
```

Your browser:

1. Asks recursive resolver
    
2. Resolver performs DNS resolution
    
3. Gets IP address
    
4. Browser connects to server
    
5. Website loads
    

`dig` [`google.com`](http://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.