# How DNS Resolution Works: From Root Servers to Your Browser

Every time you open a website, something invisible but critical happens **before** any HTTP request is sent.

You type:

```bash
google.com
```

Your browser needs:

```bash
142.250.xxx.xxx
```

That translation is done by **DNS**.

This blog explains **how DNS resolution works step by step**, using the `dig` command to expose what normally happens behind the scenes.

## DNS: The Internet’s Phonebook

Computers don’t understand domain names.

They understand **IP addresses**.

DNS (Domain Name System) exists to answer one simple question:

> “Which IP address belongs to this domain name?”

You can think of DNS as the **internet’s phonebook**:

* Domain name → Contact name
    
* IP address → Phone number
    

Without DNS, you would need to remember IP addresses for every website you visit.

## Why DNS Resolution Is Layered

There is no single server that knows all domain names.

Instead, DNS is designed as a **hierarchical, distributed system**:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768886226152/c671fe94-57a9-4bc1-998f-05710e0168ea.png align="center")

This design makes DNS:

* Scalable
    
* Fault tolerant
    
* Globally distributed
    

To understand this properly, we need a tool.

## Introducing `dig`: Your DNS Debugging Tool

`dig` (Domain Information Groper) is a command-line tool used to:

* Inspect DNS records
    
* Debug DNS issues
    
* Understand resolution paths
    

It shows **what DNS servers respond**, not just the final IP.

Think of `dig` as:

> “X-ray vision for DNS”

## Step 1: Root Name Servers

### `dig . NS`

Let’s start from the top of the DNS hierarchy.

```bash
dig . NS
```

### What This Means

* `.` represents the **DNS root**
    
* `NS` asks for **name server records**
    

### What You Learn

This command returns a list of **root name servers**, like:

```bash
a.root-servers.net
b.root-servers.net
...
```

### Important Insight

Root servers **do not know IP addresses** for domains.

They only know:

> “Who is responsible for `.com`, `.org`, `.net`, etc.”

Root servers are **traffic directors**, not databases.

## Step 2: TLD Name Servers

### `dig com NS`

Now let’s ask:

> “Who manages `.com` domains?”

```bash
dig com NS
```

### What This Does

* Queries DNS for **name servers of the** `.com` TLD
    

### What You Learn

You’ll get name servers like:

```bash
a.gtld-servers.net
b.gtld-servers.net
```

### Key Point

TLD servers:

* Do NOT know IP addresses for [`google.com`](http://google.com)
    
* They only know **which authoritative servers are responsible**
    

Think of TLD servers as:

> “The department that knows who owns which domain”

## Step 3: Authoritative Name Servers

### `dig` [`google.com`](http://google.com) `NS`

Now we ask:

> “Who is authoritative for [`google.com`](http://google.com)?”

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

### What This Returns

You’ll see Google’s authoritative name servers, such as:

```bash
ns1.google.com
ns2.google.com
```

### Why This Matters

Authoritative servers:

* Own the DNS records
    
* Provide final answers
    
* Are the **source of truth**
    

Everything above this layer just points you **closer** to the answer.

## Step 4: Full DNS Resolution

### `dig` [`google.com`](http://google.com)

Now let’s ask the real question:

```bash
dig google.com
```

### What Happens Behind the Scenes

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768886600629/c25e32fa-5ecc-4bd7-9171-ab595ff1bc9b.png align="center")

Even though `dig` gives you a final answer quickly, **this is what actually happens internally**:

1. Resolver asks **Root server**  
    → “Who handles `.com`?”
    
2. Resolver asks **TLD server**  
    → “Who handles [`google.com`](http://google.com)?”
    
3. Resolver asks **Authoritative server**  
    → “What is the IP for [`google.com`](http://google.com)?”
    
4. Resolver returns IP to client
    

This process is called **recursive resolution**.

## Understanding NS Records (Why They Matter)

NS (Name Server) records answer this question:

> “Who should I ask next?”

They don’t give IPs.  
They give **directions**.

DNS resolution is basically:

> Asking better questions until you reach the source of truth.

## Recursive Resolvers: The Unsung Heroes

Your browser does **not** talk to root servers directly.

Instead, it talks to a **recursive resolver**, usually provided by:

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

Recursive resolvers:

* Perform the full lookup
    
* Cache results
    
* Speed up future requests
    

This is why DNS feels instant after the first lookup.

## How This Connects to a Real Browser Request

When you type [`https://google.com`](https://google.com):

1. Browser asks resolver for IP
    
2. DNS resolution happens (often from cache)
    
3. Browser gets IP address
    
4. TCP connection starts
    
5. TLS handshake happens
    
6. HTTP request is sent
    

DNS is the **first domino** in every web request.

If DNS fails:

* Nothing else works
    

## Why DNS Knowledge Matters for System Design

Understanding DNS helps you:

* Debug production issues
    
* Design highly available systems
    
* Understand load balancers and CDNs
    
* Configure custom domains correctly
    
* Reason about latency and caching
    

DNS is not “networking trivia”.  
It’s **core infrastructure**.

## The Mental Model to Keep

Remember this flow:

```bash
Domain Name
   ↓
Recursive Resolver
   ↓
Root Server
   ↓
TLD Server
   ↓
Authoritative Server
   ↓
IP Address
```

DNS is not magic.  
It’s a **well-designed, layered lookup system**.

## Final Thoughts

Most developers use DNS every day without understanding it.

But once you see how resolution actually works:

* Errors make sense
    
* Outputs stop looking scary
    
* System design decisions become clearer
    

DNS is the quiet backbone of the internet —  
and now you know how it works.