# How DNS Resolution Works

Have you ever wondered how your browser knows where to go when you type `google.com`? It feels like magic, but it’s actually a very organized system called **DNS**.

So, **what is DNS**?

“DNS (Domain Name System) is the internet’s phonebook that knows whom to talk to next. It maps easy-to-remember domain names to IP addresses that computers use to identify each other.”

But, Before any of this, **How DNS even resolve it?** meaing before getting ip address what happen?

To understand how DNS resoulation work, we have one of the famous tool called `dig` to see exactly how the internet finds a website, step by step.

so, As we all know DNS records like A, NS, AAAA, CNAME, MX. TXT etc by now.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769781253811/e37058a3-dfe3-4dba-86d9-6cd6ac5be7a2.jpeg align="center")

When you type [`google.com`](http://google.com) into a browser, it checks its **cache for the IP address**, and if not found, sends a request to a **Recursive DNS Resolver**, which queries a **Root DNS server**, then a `.com` **TLD server**, and finally the **authoritative name server** to get Google's IP address, caching results along the way for faster future access.

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

The `dig` command is a tool used to ask the DNS phonebook questions directly. While browser does this work in secretly but `dig` lets us see the conversation.

so, when it is used?

* It is mostly used to check if your website settings are correct or to find out why a site isn't loading.
    
* If you move your website to a new host (like moving to Cloudflare), you can use `dig` to check if the rest of the world has seen your new "address" yet.
    
* Sometimes a service like Google or Microsoft will ask you to add a "secret code" (a TXT record) to your DNS to prove you own the site. You use `dig` to make sure that code is visible to them.
    

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

When we talk about the DNS journey, we always start at the very top. In the world of DNS, the entire internet starts with a single dot `.`This is called the **Root**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769863338953/4c922d63-a590-4977-87c7-37c7826e3595.png align="center")

**What are Root Name Servers?**

Imagine Root Name Servers are like entrance librarians in a giant internet library.  
They don’t know where google.com is, but they know where the “.com” section lives — and every search starts by asking them first.

There are **13 sets** of these root servers around the world (named `a.root-servers.net` through `m.root-servers.net`). They are the most important servers on the internet because every single search starts with them.

**Using** `dig . NS`

When you want to see these "Grand Librarians" for yourself, you use the command: `dig . NS`

* **The** `.` (Dot): This is the shortcut for "The Root."
    
* **The** `NS`: This tells the tool, "Show me the **Name Servers** in charge of this area."
    

**What happens in the background?**

When you run this command, `dig` shows you the list of the 13 root servers.

In a real-life resolution flow, your computer asks one of these root servers: *"I am looking for google.com. Do you have the IP address?"*

The Root Server answers: *"I don't have the IP address for google.com, but I see that it ends in* ***.com***\*. Here is a list of the\* ***TLD Name Servers*** *that handle all .com domains. Go ask them!"*

**Without this step, your computer wouldn't know which direction to go.** The root name servers give the "first push" that eventually leads you to the website.

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

Once the Root server gives us that "first push," we arrive at the second layer: the **TLD (Top-Level Domain) servers**.

**What are TLD Name Servers?** If the Root Server is the librarian at the front door, the **TLD Name Server** is the person in charge of a specific section, like the ".com" section or the ".org" section.

TLD stands for **Top-Level Domain**. Every ending you see on the internet (.com, .net, .dev, .org) has its own group of TLD servers. They don't have the final IP address yet, but they know exactly who the **Authoritative Owner** of the domain is.

**Using** `dig com NS` To see the "Section Leaders" for all `.com` websites, you use the command: `dig com NS`

* `com`: This tells the tool we are looking at the ".com" neighborhood.
    
* `NS`: Just like before, we are asking for the **Name Servers** in charge.
    

How they work together:

* **The Root Layer (**`dig . NS`): You ask the Root about `google.com`. It points you to the `.com` TLD servers.
    
* **The TLD Layer (**`dig com NS`): You ask the `.com` TLD server about `google.com`.
    
    * The TLD server looks at its list and says: *"I don't have the IP address, but I know that Google manages its own records. Here are the* ***Authoritative Name Servers*** *for Google. Go ask them for the final answer!"*
        

Now we have reached the final and most important destination in the DNS journey: the **Authoritative Name Server**.

### Understanding `dig google.com NS` and Authoritative Name Servers

This is the "Owner" layer. While the Root and TLD servers gave us directions, the **Authoritative Name Server** actually holds the keys to the house. It is the only server allowed to give a final, "official" answer.

**What are Authoritative Name Servers?** If the Root is the front desk and the TLD is the section leader, the **Authoritative Name Server** is the actual book you are looking for. It contains the master file (the Zone File) for a specific domain like `google.com` or `ygshjm.dev`.

**Using** `dig google.com NS` To see who is officially in charge of Google’s records, you type: `dig google.com NS`

* **Result:** You will see names like `ns1.google.com`.
    
* **The Answer:** This tells the internet: *"If you want to know anything about google.com, these are the only servers you should trust for the final answer."*
    

### Understanding `dig google.com NS` and authoritative name servers

Now, let's look at the final step where we get the actual "phone number" (IP address). When you run the simple command `dig google.com`, you are seeing the result of the entire flow working together.

**The Full Flow (How it all fits):** When you type a website name into your browser, it happens in this exact order:

1. **The Recursive Resolver:** Your computer asks a "middleman" (like Cloudflare or your ISP) to find the address.
    
2. **The Root (**`dig . NS`): The middleman asks the Root, "Where is .com?" The Root points to the TLD.
    
3. **The TLD (**`dig com NS`): The middleman asks the TLD, "Where is google.com?" The TLD points to Google's Authoritative servers.
    
4. **The Authoritative Server (**`dig google.com NS`): The middleman asks these servers, "What is the IP address?"
    
5. **The A Record (**`dig google.com`): The Authoritative server finally says: "The IP is `142.250.190.46`."
    

**The Final Answer Section** When you run `dig google.com`, look at the **ANSWER SECTION**. You will see: `google.com. 300 IN A 142.250.190.46`

* **A:** This is the **Address Record**.
    
* **The Number:** This is the IP address your browser uses to actually load the website.