# How DNS Resolution Works

Hey there developers!

Every single day, you type things like:

* [`google.com`](http://google.com)
    
* [`github.com`](http://github.com)
    
* [`api.myapp.com`](http://api.myapp.com)
    

And magically… the website loads.

But here’s the real question:

> How does the internet know where [`google.com`](http://google.com) lives?  
> Who translates this name into an IP address?  
> And how does this process *actually* work under the hood?

That’s where **DNS** comes in.

Today, we’ll break DNS down **layer by layer**, exactly how it works in the real world.

No memorization.  
Just a clean mental model.

## What is DNS and Why Name Resolution Exists

Let’s start with the obvious.

Computers **do not understand domain names**.

They understand **IP addresses**, like:

```plaintext
142.250.195.46
```

Humans, on the other hand, prefer:

```plaintext
google.com
```

So we need a system that:

* Translates names → IP addresses
    
* Works globally
    
* Scales to billions of requests
    

That system is **DNS (Domain Name System)**.

### Simple definition

**DNS is the internet’s phonebook**

You give it a name.  
It gives you the number.

## High-Level DNS Resolution Flow

Before diving into commands, let’s see the big picture.

When you type [`google.com`](http://google.com) in your browser:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769755897322/46dbde5d-d303-42ae-b08e-e2aea6061b40.jpeg align="left")

Now let’s understand **each step**, using `dig`.

## What is the `dig` Command and When It Is Used

`dig` stands for:

> **Domain Information Groper**

It’s a DNS **diagnostic tool**.

Developers use `dig` to:

* Inspect DNS records
    
* Debug DNS issues
    
* Understand resolution paths
    
* Verify production setups
    

Unlike browsers, `dig` shows you:  
*what DNS is actually doing*

## DNS Resolution Happens in Layers

DNS is **hierarchical**, not flat.

Think of it like this:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769755816054/28dc619b-6d09-406b-b1ea-716c6533e9cc.jpeg align="left")

Each layer knows **only one thing**:

> “Who is responsible for the next layer?”

This is the key idea to understand DNS.

## `dig . NS` → Root Name Servers

Let’s start at the top.

```plaintext
dig . NS
```

### What does this mean?

* `.` represents the **root of DNS**
    
* `NS` means *Name Servers*
    

This command asks:

> Who are the name servers for the root?

### Root Name Servers

Root servers:

* Don’t know IPs for websites
    
* Only know **where TLD servers are**
    

There are 13 logical root servers (A–M), operated globally.

Root servers are **starting points**, not answer machines.

## `dig com NS` → TLD Name Servers

Next level down.

```plaintext
dig com NS
```

Now you’re asking:

> Who manages `.com` domains?

### What TLD servers do

TLD servers:

* Don’t know IPs for [`google.com`](http://google.com)
    
* Know **which authoritative servers manage each domain**
    

So `.com` servers reply with:

> “Ask Google’s name servers.”

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

Now we’re getting closer.

```plaintext
dig google.com NS
```

This asks:

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

The response lists Google’s **authoritative DNS servers**.

### Why NS records matter

NS records define:

* Ownership
    
* Control
    
* Source of truth
    

Whoever controls authoritative servers controls the domain.

## `dig` [`google.com`](http://google.com) → Full DNS Resolution

Now the final step.

```plaintext
dig google.com
```

This returns:

* A record (IPv4)
    
* Possibly AAAA record (IPv6)
    

Example:

```plaintext
google.com.  A  142.250.xxx.xxx
```

This is the IP your browser actually uses.

## How Recursive Resolvers Use All This

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

Instead, it asks a **recursive resolver**, usually provided by:

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

### Recursive resolver’s job

1. Ask root servers
    
2. Ask TLD servers
    
3. Ask authoritative servers
    
4. Cache the result
    
5. Return the IP to your browser
    

This is why DNS is fast after the first lookup.

## Mapping `dig` Commands to DNS Stages

Let’s connect everything.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769756450592/ac23b097-9732-4aa0-ad66-22c2742249d2.jpeg align="left")

Each command reveals **one layer** of the DNS hierarchy.

## Connecting DNS to Real Browser Requests

When you type:

```plaintext
https://google.com
```

What actually happens:

1. Browser asks recursive resolver
    
2. Resolver finds IP via DNS hierarchy
    
3. Browser opens TCP connection
    
4. TLS handshake happens
    
5. HTTP request is sent
    

DNS is **step zero** of the entire web.

If DNS fails:  
Nothing else matters.

## Why This Matters for Backend & System Design

As a software engineer:

* Load balancers rely on DNS
    
* Failover uses DNS
    
* CDNs are DNS-based
    
* Multi-region systems depend on DNS
    

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

## Mental Model to Remember

Think of DNS as:

* A **hierarchical directory**
    
* Delegation at every level
    
* No server knows everything
    
* Each server knows *who to ask next*
    

Once this clicks:

* `dig` output makes sense
    
* DNS debugging becomes logical
    
* System design discussions feel clearer