How DNS Resolution Works

Welcome back! In the last blog, we learned about the "Phonebook" (DNS Records).

When you type a URL, your browser doesn't magically know the IP. It has to ask someone. And if that person doesn't know, they ask someone else. This chain of asking is called DNS Resolution.

Today, we are going to be "Detectives". We will use a special command called dig to manually track down an IP address, step by step.

What is DNS Resolution?

Think of it like this: You want to find "Mayur's House" (google.com), but you don't know the address.

1. You first ask the Global Chief (Root). He says, "I don't know, but I know the manager of .com."

2. Then you ask the .com Manager (TLD). He says, "I don't know, but I know who manages google."

3. Again you ask the Google Manager (Authoritative). He says, "Yes! Here is the address."

This chain is how the internet works.

dig

To see this happening live, developers use a command called dig (Domain Information Groper). It is a Linux command that lets us talk directly to DNS servers. (Note for Windows users: This tool isn't installed by default, so we usually run this in a Linux terminal or Cloud Shell).

Let’s start our investigation.

Root Name Servers

The journey starts at the very top. The Root Servers. These are the most important servers on the internet. There are 13 logical root servers in the world.

Command:

dig . NS

• . means "Root" (The starting point).

• NS means "Tell me the Name Servers" (Who is the boss?).

Terminal Output:

What happened?
We asked "Who runs the internet?". The response gave us a list from a.root-servers.net to m.root-servers.net. These are the Watchman. They don't know where google.com is, but they know who runs .com.

TLD Name Servers

Now that we know the Root, we need to find who manages the .com ending. These are called Top-Level Domain (TLD) Servers.

Command:

dig com NS

Terminal Output:

What happened?
The Root server pointed us to the gTLD servers (Global Top-Level Domain). These servers manage every single website that ends in .com.

Authoritative Name Servers

We are getting closer. The TLD server knows about .com, so now we ask it: "Who specifically handles google.com?" This takes us to the Authoritative Name Server. This is the specific server that the owner (Google) configured to handle their traffic.

Command:

dig google.com NS

Terminal Output:

What happened?
The TLD manager said, "Go ask ns1.google.com. They have the final list."

Final Answer (Full Resolution)

Now we are at the final destination. We ask the Authoritative Server: "Give me the IP address for google.com."

Command:

dig google.com

(Note: By default, dig asks for the 'A Record')

Terminal Output:

Result: We found it! The IP addresses like 74.125.68.100…

Recursive vs. Iterative:

You might be thinking, "Wait, my browser does all 4 steps every time I click a link?" No. That would be too slow.

There are two ways to resolve a name:

1. Iterative (What we just did): You run around asking Root -> TLD -> Auth yourself.

2. Recursive (The Real World): Your laptop asks one server (usually your ISP or Google 8.8.8.8) and says, "Bro, go find this for me."

Your browser is the "Lazy Friend" (Recursive). It asks the ISP. The ISP does the hard work (Iterative) of running around the internet to find the answer, and then just gives the final IP to your browser.

Conclusion

So, DNS Resolution is basically a chain of referrals.

• Root (.) says: "Ask .com"

• TLD (.com) says: "Ask Google"

• Authoritative (google.com) says: "Here is the IP: 142.250..."

It’s a beautiful system that keeps the internet organized. Next time your internet is slow, just remember the poor ISP server running around asking all these managers for directions!

Now that we have the IP address, we need to travel there to deliver our data. But how do we drive? Do we take the safe, slow family car? Or the fast, off-road rally jeep?

In the next blog, we will learn about TCP vs UDP using a Mahindra Thar analogy.