# How DNS Resolution Works

If you use the internet, you use DNS — even if you never heard of it before.

When you type google.com in your browser, something in the background has to figure out:

“What IP address is google.com?”

That “something” is the **DNS system**, and dig is a tool that lets you **see** what is going on under the hood.

In this article, we will look at:

* **What DNS is and why name resolution exists**
    
* **What the dig command is and when it is used**
    
* **How DNS resolution happens in layers**: root → TLD → authoritative
    
* **How dig. NS, dig com NS, dig** [**g**](http://google.com)**oogle.com, and dig google.com all connect**
    

Language will stay simple and practical. Think of this as a gentle networking lesson for beginners who want to understand how the internet actualy works.

## 1\. What is DNS? (The Internet’s Phonebook)

### 1.1 Humans like names, computers like numbers

* Humans like **names**: google.com, facebook.com, myblog.dev.
    
* Computers use **IP addresses**: 142.250.72.14 or 2404:6800:4004:81b::200e.
    

Remembering all these IPs would be painful and impossible. So we use **DNS – Domain Name System**.

**DNS is like a huge distributed phonebook** for the internet:

* **You**: “What is the IP address of google.com?”
    
* **DNS**: “Here you go: 142.250.72.14” (example).
    

This process of turning a **name** (like google.com) into an **IP address** is called **name resolution**.

### 1.2 Why does name resolution exist?

Name resolution exists because:

* **Humans think in names**, not numbers.
    
* Websites can **change servers or IP addresses** in the background.
    
* DNS lets us keep a **stable domain name** while changing the underlying infrastructure.
    

This extra layer also helps with:

* **Load balancing**: many IPs for one domain.
    
* **High availability**: switch IPs if a server is down.
    
* **Geo-routing**: show a different IP (closer server) depending on where the user is.
    

So DNS is not just a phonebook. It is also a **smart routing and abstraction layer** for the internet.

---

## 2\. What is dig, and when is it used?

dig means **Domain Information Groper**. Yes, the name is a bit strange. But it’s very useful.

### 2.1 What dig does

dig is a **command-line tool** that asks questions to DNS servers. For example:

```bash
dig google.com
```

This command sends a DNS query and shows:

* What you asked
    
* What answer came back
    
* Which records and servers were involved
    

With dig, you can ask things like:

* “What is the IP address of google.com?”
    
* “Which name servers are responsible for com?”
    
* “Which name servers are authoritative for shivam-goyal.site?”
    

### 2.2 When you use dig (in real life)

You use dig when you:

* **Debug DNS problems**
    

“My domain is not working, why?”

* **Check DNS propagation**
    

“I changed a record – did the internet see it yet?”

* **Learn how DNS works**
    

See each step of the resolution process.

* **Do system design / DevOps / backend work**
    

DNS is part of almost every non-trivial system.

If you are serious about backend, cloud, or DevOps, knowing dig is almost like knowing curl for HTTP.

---

## 3\. DNS Hierarchy: Root → TLD → Authoritative

Before we start playing with dig, we need to understand the **DNS hierarchy**.

Think of DNS like a big tree:

* **Root (.)** – at the very top.
    
* **TLDs (Top-Level Domains)** – .com, .org, .net, .io, .in, etc.
    
* **Domains** – google.com, example.com, myblog.io.
    
* **Subdomains** – www.google.com, api.myblog.io, etc.
    

### 3.1 Who knows what?

* **Root servers**:
    

Know which servers handle each **TLD** (like .com, .org).

* **TLD servers** (for .com):
    

Know which servers handle each **domain** under .com (like google.com, facebook.com).

* **Authoritative servers** (for google.com):
    

Know the **actual records** for that domain (IP addresses, mail servers, etc).

Your **recursive resolver** (usually your ISP DNS or something like 8.8.8.8 or 1.1.1.1) walks this tree to find answers.

---

## 4\. dig. NS – Root Name Servers

Now let’s map commands to layers, starting from the top.

### 4.1 What dig. NS means

```bash
dig. NS
```

* . → the **root zone** (top of the DNS hierarchy)
    
* NS → **Name Server record** type
    

You are basically asking:

“Which name servers are responsible for the root of the DNS system?”

### 4.2 What you will see (conceptually)

You will see root servers like:

* a.root-servers.net
    
* b.root-servers.net
    
* …
    
* m.root-servers.net
    

There are **13 logical root name servers** (A to M), but each one is actually a **large cluster of machines** across the world.

### 4.3 Why root name servers matter

* They are the **first step** when nothing is cached.
    
* They **do not** know the IP of google.com.
    
* They **do know** which name servers handle .com, .org, .net, etc.
    

They basically say:

“I don’t know google.com, but here is who knows about .com. Go ask them.”

---

## 5\. dig com NS – TLD Name Servers

Now we move one level down: the TLD (Top-Level Domain).

### 5.1 What does dig com NS means

```bash
dig com NS
```

This means:

“Which name servers are responsible for the .com TLD?”

### 5.2 What you will see

You will see something like:

* a.gtld-servers.net
    
* b.gtld-servers.net
    
* …
    
* m.gtld-servers.net
    

These are **TLD name servers** for .com.

### 5.3 What TLD servers do

TLD servers for .com don’t know all the IPs, but they know:

* “For google.com, these are the authoritative name servers.”
    
* “For facebook.com, these other servers are authoritative.”
    

So for our google.com question, a .com TLD server basically says:

“I don’t know the IP of google.com, but I know which servers are authoritative for google.com. Ask them.”

---

## 6\. dig google.com NS – Authoritative Name Servers

Now we reach the domain itself.

### 6.1 What dig google.com NS means

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

This means:

“Which name servers are authoritative for google.com?”

### 6.2 What you will see

Something like:

* ns1.google.com
    
* ns2.google.com
    
* ns3.google.com
    
* ns4.google.com
    

(Names and numbers may differ, but the idea is the same.)

These are **authoritative name servers** for the google.com zone.

### 6.3 What authoritative servers do

Authoritative servers are the **source of truth** for a domain. They know:

* **A / AAAA records** – IP addresses for google.com, www.google.com, etc.
    
* **MX records** – mail servers.
    
* **TXT records** – SPF, verification, etc.
    
* **CNAME records** – aliases, and more.
    

So when they get the question:

\> “What is the IP address (A record) for google.com?”

They can answer directly, for example:

\> “A record for google.com is 142.250.72.14” (example IP, may change in reality).

From a system design point of view, this is where your DNS configuration for your domain lives (often in a DNS provider or cloud panel).

---

## 7\. dig google.com – The Full DNS Resolution Flow

Now the most common thing you do with dig.

### 7.1 What does dig google.com does

```bash
dig google.com
```

By default, this asks your **configured recursive resolver** (like 8.8.8.8, 1.1.1.1, or your ISP resolver):

1. It checks its **cache** first.
    
2. If not cached, it does the full walk:
    

* Ask a **root** server: “Who handles .com?”
    
* Ask a **.com TLD** server: “Who handles [google.com](http://google.com)?”
    
* Ask a **google.com authoritative** server: “What is the A record for google.com?”
    

1. It returns the final answer to dig.
    

dig then shows you:

* **QUESTION SECTION** – What you asked.
    
* **ANSWER SECTION** – The IP addresses or records you got.
    
* Maybe **AUTHORITY / ADDITIONAL** sections – extra data about name servers and helper records.
    

### 7.2 Why you don’t always see every hop

In a simple dig google.com, you usually don’t see each step (root, .com, etc.) because:

* Your **recursive resolver hides this work**.
    
* Many answers may already be in **cache**.
    

But the logical steps still exist behind the scenes. To see all hops in detail, you can later try:

```bash
dig +trace google.com
```

This walks and prints every step (root → TLD → authoritative).

---

## 8\. How Recursive Resolvers Use These Layers

Let’s imagine nothing is cached, and you ask for google.com.

### 8.1 Step-by-step flow

1. **Browser**: “I need https://google.com.”
    
2. **Operating System**: “I need the IP for google.com.”
    
3. **Recursive Resolver** (DNS server you configured):
    

* **Step 1 – Ask Root**
    
* “Who knows about .com?”
    
* Root replies with **NS records** for .com TLD servers.
    
* **Step 2 – Ask .com TLD**
    
* “Who knows about google.com?”
    
* TLD replies with **NS records** for google.com authoritative servers.
    
* **Step 3 – Ask google.com authoritative information**
    
* “What is the A record for [google.com](http://google.com)?”
    
* The authoritative server replies with the **IP address**.
    
* **Step 4 – Cache results**
    
* Resolver stores these results for some time (TTL – Time To Live) to answer future queries faster.
    

1. Resolver returns the IP to your OS, which gives it to your browser.
    
2. Browser now opens a TCP/TLS connection to this IP and starts the HTTP / HTTPS request.
    

### 8.2 Mapping this to dig commands

Each dig command is like zooming in on one step:

```bash
dig. NS → Root layer – who knows the TLDs.

dig com NS → TLD layer – who knows google.com.

dig google.com NS → Authoritative layer – who knows the records for google.com.

dig google.com → Final answer – what the user actually needs (IP)
```

This mapping is very helpful when you learn system design or need to debug weird DNS issues.

---

## 9\. How This Relates To Real Browser Requests

Every time you visit a website:

* Before your browser sends **HTTP/HTTPS** traffic…
    
* It usually does a **DNS lookup** first (unless already cached).
    

So:

* **Performance**: Slow DNS = web page feels slow, even before anything loads.
    
* **Reliability**: DNS misconfiguration = site seems “down” even if servers are fine.
    
* **Routing & scaling**:
    
* CDNs use DNS to send you to the nearest edge.
    
* Multi-region apps use DNS to split traffic.
    
* Failover strategies often update DNS records.
    

Knowing a bit of dig and DNS puts you in a much better position to design, debug, and scale systems.

---

## 10\. Quick Recap

* **DNS** is the **Internet’s phonebook**, mapping domain names to IP addresses.
    
* **Name resolution** exists because humans like names, machines need IPs, and we want flexibility and indirection.
    
* **dig** is a simple but powerful **DNS diagnostic tool**.
    
* DNS is structured in layers:
    
* **Root**: dig. NS
    
* **TLD (.com)**: dig com NS
    
* **Authoritative (google.com)**: dig google.com NS
    
* **Final answer (A/AAAA)**: dig google.com
    
* **Recursive resolvers** walk through these layers for you, cache answers, and serve your apps and browsers behind the scenes.
    
* Understanding this flow is very useful for **system design, DevOps, backend, and debugging real-world issues**.
    

If you want to practice, open a terminal and try in this order:

```bash
dig. NS

dig com NS

dig google.com NSdig google.com
```

**Happy Learning! 🚀**

*Have questions about how browsers work? Drop them in the comments!*