# How DNS Resolution Works ( A Practical, Layer-by-Layer Story)

Think of DNS as **the internet’s phonebook**. Humans remember names like [`google.com`](http://google.com), but computers talk in IP addresses like `142.250.72.14`. DNS exists to bridge that gap turning readable names into routable addresses, billions of times a day, in milliseconds.

As engineers, DNS is one of those systems that *just works* until it doesn’t. And when it breaks, knowing how resolution actually works becomes priceless.

Let’s build that understanding step by step.

---

## What Is DNS and Why Name Resolution Exists

At its core, **DNS (Domain Name System)** is a globally distributed, hierarchical database.

Why hierarchical?  
Because no single system could realistically store or serve the entire internet’s naming data. Instead, DNS is split into **layers of responsibility**, each answering only what it knows.

This design gives us:

1. Scalability (no central bottleneck)
    
2. Fault isolation
    
3. Delegated ownership (Google controls [`google.com`](http://google.com), not ICANN)
    

## Introducing `dig`: Your DNS Debugging Microscope

`dig` (Domain Information Groper) is a diagnostic tool that lets you *inspect DNS resolution*, step by step.

When a browser makes a request, all this DNS work happens invisibly. `dig` lets us slow time down and watch the gears turn.

We’ll use it to query -

1. Root name servers
    
2. TLD name servers
    
3. authorotative name servers
    

### `dig . NS` - Root Name Servers

```bash
dig . NS
```

This asks: *“Who is responsible for the root of DNS?”*

The response lists **root name servers** ([`a.root-servers.net`](http://a.root-servers.net), [`b.root-servers.net`](http://b.root-servers.net), etc.).

Key insight:

1. Root servers **don’t know IPs for domains**
    
2. They only know **which servers handle each TLD** (`.com`, `.org`, `.net`)
    

They are traffic directors, not data stores.  

### `dig com NS` - TLD Name Servers

```bash
dig com NS
```

Now we ask: *“Who manages* `.com`?”

These **TLD (Top Level Domain) servers** know -

1. Which authoritative servers are responsible for [`ggoogle.com`](http://google.com)
    
2. But not Google’s IP addresses themselves
    

Think of TLD servers as **regional offices** closer to the data, but still not the source of truth.

### `dig` [`google.com`](http://google.com) `NS` - Authoritative Name Servers

```bash
dig google.com NS
```

This returns Google’s **authoritative name servers**.

Important concept -

1. **NS records** define *delegation*
    
2. They say: *“These servers are the source of truth for this domain”*
    

Authoritative servers are where real answers live -

1. A / AAAA records
    
2. MX records
    
3. TXT records
    

### `dig google.com` - Full DNS Resolution

```bash
dig google.com
```

This is what your browser effectively triggers.

Behind the scenes, a **recursive resolver** (usually your ISP or public DNS like 8.8.8.8) does the work:

1. Ask root servers → *Who handles* `.com`?
    
2. Ask TLD servers → *Who handles* [`google.com`](http://google.com)?
    
3. Ask authoritative servers → *What is the IP?*
    
4. Cache the answer and return it to the client
    

Your browser just waits for the final IP.

## Step by Step DNS Resolution for [`google.com`](http://google.com)

1. Browser asks the OS resolver
    
2. OS asks recursive resolver
    
3. Recursive resolver queries root servers
    
4. Root → TLD servers
    
5. TLD → authoritative servers
    
6. Authoritative → IP address
    
7. IP returned → TCP/TLS/HTTP begins
    

DNS finishes before your first HTTP byte is sent.

## Why This Matters in System Design

1. DNS caching hides latency but introduces **staleness**
    
2. TTL tuning affects failover and resilience
    
3. Multi-region systems rely heavily on DNS-based routing
    
4. Outages often look like “the internet is broken” but are DNS misconfigurations
    

understanding DNS isn’t optional, it’s foundational.