How DNS Resolution Works: From Domain Name to IP Address

Every time you open a website, something quiet but critical happens in the background.

You type a name like:

google.com

Your computer does not understand names.

It understands IP addresses.

So the real question is:

> How does a human-friendly name turn into a machine-friendly address?

That process is called DNS resolution.

Let’s break it down step by step, slowly, and in the same order the internet actually uses.

DNS: the internet’s phonebook

DNS stands for Domain Name System.

The easiest way to think about DNS is this:

> DNS is the internet’s phonebook.

• You remember names like google.com
• Computers need numbers like 142.250.195.46

DNS exists because remembering numbers would be painful for humans.

So DNS sits in the middle and does the translation.

Why name resolution exists

When your browser wants to open a website, it needs to:

1. Find the server’s IP address
2. Open a network connection to that IP

Without DNS:

• You would need to type IP addresses
• Websites could not change servers easily
• The internet would be fragile and unreadable

DNS solves all of that.

Introducing `dig`: looking inside DNS

Most of the time, DNS works invisibly.

But as developers, we need a way to see what’s happening.

That’s where dig comes in.

dig stands for Domain Information Groper.

It is a command-line tool used to:

• Inspect DNS records
• Debug DNS issues
• Understand how resolution actually works

Think of dig as an X-ray machine for DNS.

The DNS hierarchy (big picture)

DNS is not one big server.

It is a hierarchy.

At the top:

Root Servers

↓

TLD Servers (.com, .org, .in)

↓

Authoritative Name Servers

Each level only knows one step down.

That design is what makes DNS scalable.

Step 1: Root name servers

Let’s start from the very top.

Run this:

dig . NS

›What does this mean?

• . represents the root
• NS asks for name servers

This command asks:

> “Who are the name servers for the root of DNS?”

›What you’ll see

You’ll get a list like:

a.root-servers.net

b.root-servers.net

...

These are the root name servers.

Important point:

> Root servers do NOT know IPs for google.com.

They only know:

• Which servers handle .com
• Which servers handle .org
• Which servers handle .in

That’s it.

Step 2: TLD name servers (.com)

Now let’s move one level down.

Run:

dig com NS

This asks:

> “Which name servers are responsible for .com?”

›What you learn here

You’ll see name servers like:

a.gtld-servers.net

b.gtld-servers.net

...

These are TLD (Top-Level Domain) servers.

They know:

• Who manages google.com
• Who manages amazon.com
• Who manages github.com

But again:

> They still do NOT know the IP address.

They only point to the next level.

Step 3: Authoritative name servers

Now let’s ask specifically about Google.

dig google.com NS

This command asks:

> “Who is authoritative for google.com?”

›What this shows

You’ll get name servers like:

ns1.google.com

ns2.google.com

...

These are authoritative name servers.

This is where truth lives.

Authoritative servers:

• Store actual DNS records
• Decide IP addresses
• Control mail routing, verification, and more

Step 4: Full DNS resolution for google.com

Now run the main command:

dig google.com

This is the full resolution.

Behind the scenes, this is what happens:

1. Ask root servers where .com lives
2. Ask .com servers where google.com lives
3. Ask Google’s authoritative servers for the IP
4. Get the final answer

The output includes:

• Answer section (IP addresses)
• Authority section
• Additional information

This is the final result your browser needs.

How recursive resolvers fit in

Your browser does not run all these steps itself.

Instead, it asks a recursive resolver.

Usually provided by:

• Your ISP
• Google DNS (8.8.8.8)
• Cloudflare (1.1.1.1)

The recursive resolver:

• Talks to root servers
• Talks to TLD servers
• Talks to authoritative servers
• Caches results for speed

Your browser just asks:

> “What is the IP for google.com?”

And gets an answer.

Why NS records matter

NS (Name Server) records define authority.

They answer questions like:

• Who controls this domain?
• Where should DNS queries go next?

Without NS records:

• DNS resolution would stop
• Domains would not work
• Ownership would be unclear

NS records are the road signs of DNS.

Connecting DNS to real browser requests

When you type google.com in your browser:

1. Browser asks recursive resolver
2. Resolver performs DNS resolution
3. IP address is returned
4. Browser opens a TCP/HTTPS connection
5. Website starts loading

DNS is always the first step.

If DNS fails, nothing else happens.

Mental model to remember

Think of DNS like asking for directions:

• Root server: “I don’t know, but .com is that way”
• TLD server: “I don’t know the address, but Google’s office is there”
• Authoritative server: “Here is the exact address”

Each level helps without knowing everything.

Final thoughts

DNS resolution is not magic.

It is a layered lookup system designed for scale and reliability.

Once you understand:

• Root → TLD → Authoritative
• NS records as pointers
• Recursive resolvers doing the heavy lifting

DNS stops being confusing.

It becomes predictable.

And that’s when debugging, system design, and backend work start to feel much clearer.