# How DNS Resolution Works

---

## What is DNS, and why do we need name resolution?

DNS is our internet’s phonebook. But there is one important difference. It never stores names and numbers in one place.

We humans prefer names like “google.com“. But computers only understand IP addresses (142.250.19.46). DNS exist to translate between the two, quickly and reliable, millions times per second.

Without DNS every website we build or visit would require use to remember raw IP addresses which is practically not possible. That’s why internet world relies on DNS where responsibility is split across multiple layers instead of one central database.

Isi design decision ki wajah se, agar internet ka koi hissa fail bhi ho jaaye, phir bhi poora internet chalna band nahi hota.

---

## What is the `dig` command and when it is used

dig —> Domain Information Groper —> is a diagnostic tool that lets us **see DNS in action**.

What happens normally? When we open a website in the browser, we don't see the entire DNS process. Browser handles everything in the background. It hides the DNS resolution process.  
`dig` removes that abstraction and shows exactly what was happening.

* which servers are being queried
    
* what records are returned
    
* how authority flows through the system
    

Matlab, DNS ke andar jo actual baat-cheet ho rahi hoti hai, **dig woh sab saamne dikha deta hai**.

**difference between cURL and dig?**  
—> **curl = HTTP ke liye**  
—> **dig = DNS ke liye**

Jaise cURL batata hai server se kya response aa raha hai, **dig batata hai DNS ke andar kya ho raha hai**.  
dig = DNS ka X-ray machine

> `dig` works natively on Linux and macOS. On Windows, it does not come by default in Command Prompt, PowerShell or in Windows Terminal. If we install **Windows Subsystem for Linux (WSL)**, we get a real Linux environment inside Windows.

---

## DNS resolution happens in layers

DNS resolution doesn’t give the answer in one go. It finds the answer by moving step by step through different levels.  
Pehle **root level** se poochta hai,  
phir **TLD (.com, .in, etc.)** ke paas jaata hai,  
aur finally **authoritative DNS server** se exact answer leta hai.

Isliye DNS ka process thoda slow lag sakta hai,  
par **yehi step-by-step design system ko reliable aur stable banata hai.**

![A Crash Course in DNS - ByteByteGo Newsletter](https://substackcdn.com/image/fetch/%24s_%21P_Ol%21%2Cf_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0a1bb2c-a1bc-40ce-abde-6fb9d2a66ce8_1600x570.png align="left")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768931622786/7d5c75d5-b4dd-4f1b-b48e-3b811a348cbb.webp align="center")

Note : TLD —> (Top-Level Domain) —> It is the **last part of a website name**.

Examples: —> .com / .in / .org / .net  
When DNS looks for a website, It first asks the **root server,** root server replies like:  
“I don’t know the exact IP, but for `.com`, ask the TLD server.”

TLD server then points to the authoritative DNS server.

Her Authoritative DNS server means the server that actually knows the correct IP of the domain.

---

## Understanding `dig . NS` — root name servers

This command asks ——> “Who is authoritative for the root of DNS?”  
Response lists root name servers like:

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

* The root zone doesn’t store domain IPs  
    means root server ye nahi batata ki “google.com” ka IP kya hai.
    
* It only knows which servers handle which TLDs  
    root server sirf itna jaanta hai ki kaunsa TLD (jaise `.com`, `.org`, `.in`) kaunsa server handle karta hai.
    
* There are multiple root servers globally, replicated using Anycast  
    Iska matlab hai hum hamesha nearest root server se baat karte hain, isliye DNS fast aur reliable rehta hai.
    

---

## Understanding `dig com NS` — TLD name servers

This command solve this:  
“Who is responsible for the `.com` namespace?”  
The response lists TLD name servers managed by registries.

Key idea:

* `.com` servers do not know IPs for “google.com”
    
* They only know **which authoritative servers are responsible for it**
    

This separation keeps DNS scalable and manageable.  
Yeh bas **direction dete hain**, exact answer nahi.

Example:

> *“Mujhe* [*google.com*](http://google.com) *ka IP nahi pata,  
> lekin yeh lo, yeh servers hain jo iska final answer de sakte hain.”*

---

## Understanding `dig` [`google.com`](http://google.com) `NS` — authoritative name servers

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

Now we’re asking ——> **“Who owns the DNS records for “google.com“?**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768932558320/4b37e9fb-73da-4b95-9789-e994ac360040.webp align="center")

---

## Understanding `dig` [`google.com`](http://google.com) — full DNS resolution

```plaintext
dig google.com
```

This command returns the final answer — IP addresses for “google.com“

When we type “google.com”, browser doesn't communicate directly with Google's servers. There's a complex journey that takes place first.

Step 1: Recursive resolver ka role ata hai:  
Sabse pehle humara system ek recursive resolver ko request karta hai (ISP DNS, Google DNS, Cloudflare DNS) —> “google.com ka IP pata hai kya?“

Step2 - Root servers se poochha jata hai  
Resolver root server se poochta hai —> google.com ka IP pata hai kya?

Step3 - `.com` TLD servers se baat hoti hai  
Ab resolver `.com` TLD server ke paas jata hai aur poochta hai —> google.com ka IP?  
TLD Server reponse karta hai —> IP mere paas bhi nahi hai, par google.com ke authoritative servers ye hain.

Direction to milti hai, final answer nahi.

Step 4: Authoritative server final answer deta hai  
Ab resolver Google ke authoritative DNS server se poochta hai —> google.com ka IP kya hai?  
Yahin se exact answer aata hai aur actual truth mil jata hai.

Step 5: Caching hoti hai  
Resolver is answer ko kuch time ke liye **cache** kar leta hai.  
Benefits - next request me root/TLD tak jane ki zarurat nahi / DNS fast hota hai

Step 6: Browser actual connection banata hai  
Ab browser ke paas IP aa chuka hota hai. DNS ka kaam khatam.

After this, the TCP connection is established, followed by the TLS handshake, and then the HTTP request is sent.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1768943215223/33547320-f728-4bfb-920f-742582413ebb.jpeg align="center")

---

## Connecting `dig` output to real browser requests

Every HTTP request starts with DNS.

* Before TLS  
    Secure connection (HTTPS / encryption) tabhi start ho sakta hai jab browser ko server ka IP address mil jaye.
    
* Before headers.  
    HTTP headers (User-Agent, Authorization etc.) tab bheje jaate hain jab connection ban chuka ho — aur connection DNS ke baad hi banta hai.
    
* Before cookies.  
    Cookies bhi HTTP headers ka hi part hoti hain, isliye **DNS ke baad** hi jaati hain.
    
* Before APIs.  
    API call bhi ek HTTP request hi hoti hai. API hit karne se pehle bhi DNS resolve hona zaroori hai.
    

DNS is the first door of the internet. Agar DNS fail ho gaya, to baaki sab (TLS, headers, cookies, APIs) kabhi start hi nahi honge.

If DNS fails:

* websites don’t load
    
* APIs appear “down”
    
* services look broken even when servers are healthy
    

---