# How DNS Resolution Works

If the internet had a **phonebook**, DNS would be it.  
Every time you type [`google.com`](http://google.com) into a browser, *something* has to translate that human-friendly name into an IP address that machines understand. That “something” is DNS resolution.

## What Is DNS and Why Name Resolution Exists

Computers don’t understand names like [`google.com`](http://google.com).  
They understand **IP addresses** like `142.250.72.14`.

Humans, on the other hand, are terrible at remembering numbers.

So DNS (Domain Name System) exists to bridge that gap:

> **DNS maps human-readable domain names to machine-readable IP addresses.**

Without DNS, the web would be a giant spreadsheet of numbers—and nobody wants that.

## DNS as the Internet’s Phonebook

Think of DNS like this:

* You know a person’s **name** ([google.com](http://google.com))
    
* You want their **phone number** (IP address)
    
* You ask a system that knows **where to look**
    

DNS doesn’t store everything in one place.  
Instead, it’s **distributed and hierarchical**, which is why it scales to the size of the internet.

## What Is the `dig` Command and When It’s Used

`dig` (Domain Information Groper) is a **DNS inspection tool**.

You use it when:

* Debugging DNS issues
    
* Learning how name resolution works
    
* Verifying which servers are authoritative
    
* Understanding how a domain is resolved step by step
    

Unlike browsers, `dig` doesn’t hide complexity—it *shows you everything*.

## DNS Resolution Happens in Layers

DNS works like a chain of referrals:

1. **Root name servers**
    
2. **TLD (Top-Level Domain) name servers**
    
3. **Authoritative name servers**
    

Each layer knows *where to send you next*.

![Explaining DNS Resolution. DNS resolution, or Domain Name System… | by  soulaimaneyahya | Medium](https://miro.medium.com/1%2AgoSb1oow5UBNF3KkzvOX8A.png align="left")

## Understanding `dig . NS` — Root Name Servers

```plaintext
dig . NS 
```

This asks:

“Who is responsible for the DNS root?”

The result is a list of root name servers ([a.root-servers.net](http://a.root-servers.net), [b.root-servers.net](http://b.root-servers.net), etc.).

Key idea:

Root servers don’t know IPs

They only know where TLDs live (.com, .org, .net)

They are the starting point of all DNS resolution.

## Understanding `dig com NS` — TLD Name Servers

```plaintext
dig com NS
```

This asks:

> “Who handles domains ending in `.com`?”

These **TLD name servers** don’t know Google’s IP either.  
What they *do* know is **which authoritative servers manage** [**google.com**](http://google.com).

Think of TLD servers as:

> “I don’t have the answer, but I know who does.”

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

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

This tells us:

* Which name servers are **authoritative for** [**google.com**](http://google.com)
    
* These servers are the **source of truth**
    

Authoritative servers:

* Store real DNS records (A, AAAA, MX, TXT)
    
* Give final, trusted answers
    

If DNS were a company:

* Root = receptionist
    
* TLD = department directory
    
* Authoritative = actual team with the data
    

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

```plaintext
dig google.com
```

This returns the **A record** (or AAAA for IPv6):

> The actual IP address your browser needs.

Behind the scenes, a **recursive resolver** has already done the work:

1. Asked the root servers
    
2. Asked the `.com` TLD servers
    
3. Asked Google’s authoritative servers
    
4. Cached the result for speed
    

## How Recursive Resolvers Fit In

You usually don’t talk to root or TLD servers directly.

Instead:

* Your device queries a **recursive resolver**
    
* Often run by your ISP, company, or public DNS providers
    
* It handles the full lookup *on your behalf*
    

Why this matters:

* **Caching** reduces latency
    
* **Load is reduced** on root and TLD servers
    
* DNS stays fast and scalable
    

## Mapping `dig` Commands to DNS Lookup Stages

| dig Command | DNS Layer |
| --- | --- |
| `dig . NS` | Root name servers |
| `dig com NS` | TLD name servers |
| `dig` [`google.com`](http://google.com) `NS` | Authoritative name servers |
| `dig` [`google.com`](http://google.com) | Final IP resolution |

## Real-World Browser Requests

When you open a browser and type [`google.com`](http://google.com):

1. Browser checks local cache
    
2. OS checks DNS cache
    
3. Recursive resolver is queried
    
4. Resolver walks the DNS hierarchy (if needed)
    
5. IP address is returned
    
6. Browser connects via TCP/HTTPS
    

DNS is invisible—but without it, **nothing on the internet works**.