# How DNS Resolution Works

When you type [`google.com`](http://google.com) in a browser, a lot happens behind the scenes before the page loads.  
That entire process is called **DNS resolution**.

Let’s break it down step by step using the `dig` command.

## 1\. What is DNS and why name resolution exists

Computers don’t understand domain names.  
They only understand **IP addresses** like `142.250.190.14`.

DNS (Domain Name System) exists to **translate human-friendly names into machine-friendly IPs**.

Think of DNS as the **internet’s phonebook**:

* Name → Phone number
    
* Domain → IP address
    

Without DNS, we’d have to remember IPs for every website.

## 2\. What is the `dig` command and when it is used

`dig` stands for **Domain Information Groper**.

It is a command-line tool used to:

* Inspect DNS records
    
* Debug DNS issues
    
* Understand how name resolution works internally
    

Unlike browsers, `dig` shows **raw DNS responses**.

Example:

```plaintext
dig google.com
```

## 3\. Understanding `dig . NS` (Root Name Servers)

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

```plaintext
dig . NS
```

This asks:

> “Who controls the root of DNS?”

The response lists **root name servers** like:

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

These servers **don’t know IPs of websites**.  
They only know **where to find TLD servers**.

Root servers are the **starting point** of every DNS lookup.

**DNS hierarchy – Root level**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769537370787/1ea908d1-a743-4026-94bf-5f490d7e3b5e.png align="center")

## 4\. Understanding `dig com NS` (TLD Name Servers)

Next layer: **Top-Level Domain (TLD)**.

```plaintext
dig com NS
```

This asks:

> “Who manages `.com` domains?”

The answer returns `.com` name servers (run by Verisign).

TLD servers:

* Don’t know IP addresses
    
* Know **which authoritative servers manage a domain**
    

**Root → TLD (.com)**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769537585283/7cf50080-4eb7-482f-adfc-e49282ae5300.png align="center")

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

Now let’s ask about a specific domain.

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

This returns Google’s **authoritative name servers** like:

```plaintext
ns1.google.com
ns2.google.com
```

Authoritative servers:

* Hold the **actual DNS records**
    
* Are the final source of truth
    

This is where real answers live.

**TLD → Authoritative servers**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769537825548/7042e825-d434-4938-b3b1-edda22f3ac19.png align="center")

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

Now the real question:

```plaintext
dig google.com
```

This returns:

* A record (IPv4 address)
    
* Sometimes AAAA (IPv6)
    
* TTL values
    

Behind the scenes, the resolver does this:

1. Ask root servers → where is `.com`?
    
2. Ask `.com` servers → where is [`google.com`](http://google.com)?
    
3. Ask Google’s authoritative servers → what is the IP?
    

Your browser **never talks directly** to root or TLD servers.  
A **recursive resolver** (ISP / Google DNS / Cloudflare) does this for you.

**Full DNS resolution flow for** [**google.com**](http://google.com)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769538169490/627cdc07-4ceb-4a31-a2f2-6186eed684ad.png align="center")

## How recursive resolvers fit in

Recursive resolvers:

* Cache DNS results
    
* Reduce latency
    
* Protect root/TLD servers from overload
    

Popular resolvers:

* `8.8.8.8` (Google)
    
* `1.1.1.1` (Cloudflare)
    

They repeat the root → TLD → authoritative process **only when needed**.

**Recursive resolver interaction**

![](https://www.researchgate.net/profile/Zhou-Li-19/publication/330006223/figure/fig1/AS:709642057445377@1546203259697/Domain-resolution-process-with-a-recursive-resolver.ppm align="left")

## Connecting DNS to real browser requests

When DNS resolution finishes:

* Browser gets IP address
    
* TCP connection starts
    
* HTTPS handshake happens
    
* HTTP request is sent
    

DNS is **step zero** of every web request.

If DNS fails, **nothing loads**.