How DNS Resolution Works: From Root Servers to Your Browser

Every time you open a website, something invisible but critical happens before any HTTP request is sent.

You type:

google.com

Your browser needs:

142.250.xxx.xxx

That translation is done by DNS.

This blog explains how DNS resolution works step by step, using the dig command to expose what normally happens behind the scenes.

DNS: The Internet’s Phonebook

Computers don’t understand domain names.

They understand IP addresses.

DNS (Domain Name System) exists to answer one simple question:

“Which IP address belongs to this domain name?”

You can think of DNS as the internet’s phonebook:

• Domain name → Contact name

• IP address → Phone number

Without DNS, you would need to remember IP addresses for every website you visit.

Why DNS Resolution Is Layered

There is no single server that knows all domain names.

Instead, DNS is designed as a hierarchical, distributed system:

This design makes DNS:

• Scalable

• Fault tolerant

• Globally distributed

To understand this properly, we need a tool.

Introducing dig: Your DNS Debugging Tool

dig (Domain Information Groper) is a command-line tool used to:

• Inspect DNS records

• Debug DNS issues

• Understand resolution paths

It shows what DNS servers respond, not just the final IP.

Think of dig as:

“X-ray vision for DNS”

Step 1: Root Name Servers

dig . NS

Let’s start from the top of the DNS hierarchy.

dig . NS

What This Means

• . represents the DNS root

• NS asks for name server records

What You Learn

This command returns a list of root name servers, like:

a.root-servers.net
b.root-servers.net
...

Important Insight

Root servers do not know IP addresses for domains.

They only know:

“Who is responsible for .com, .org, .net, etc.”

Root servers are traffic directors, not databases.

Step 2: TLD Name Servers

dig com NS

Now let’s ask:

“Who manages .com domains?”

dig com NS

What This Does

• Queries DNS for name servers of the .com TLD

What You Learn

You’ll get name servers like:

a.gtld-servers.net
b.gtld-servers.net

Key Point

TLD servers:

• Do NOT know IP addresses for google.com

• They only know which authoritative servers are responsible

Think of TLD servers as:

“The department that knows who owns which domain”

Step 3: Authoritative Name Servers

dig google.com NS

Now we ask:

“Who is authoritative for google.com?”

dig google.com NS

What This Returns

You’ll see Google’s authoritative name servers, such as:

ns1.google.com
ns2.google.com

Why This Matters

Authoritative servers:

• Own the DNS records

• Provide final answers

• Are the source of truth

Everything above this layer just points you closer to the answer.

Step 4: Full DNS Resolution

dig google.com

Now let’s ask the real question:

dig google.com

What Happens Behind the Scenes

Even though dig gives you a final answer quickly, this is what actually happens internally:

1. Resolver asks Root server
   → “Who handles .com?”

2. Resolver asks TLD server
   → “Who handles google.com?”

3. Resolver asks Authoritative server
   → “What is the IP for google.com?”

4. Resolver returns IP to client

This process is called recursive resolution.

Understanding NS Records (Why They Matter)

NS (Name Server) records answer this question:

“Who should I ask next?”

They don’t give IPs.
They give directions.

DNS resolution is basically:

Asking better questions until you reach the source of truth.

Recursive Resolvers: The Unsung Heroes

Your browser does not talk to root servers directly.

Instead, it talks to a recursive resolver, usually provided by:

• Your ISP

• Google DNS (8.8.8.8)

• Cloudflare DNS (1.1.1.1)

Recursive resolvers:

• Perform the full lookup

• Cache results

• Speed up future requests

This is why DNS feels instant after the first lookup.

How This Connects to a Real Browser Request

When you type https://google.com:

1. Browser asks resolver for IP

2. DNS resolution happens (often from cache)

3. Browser gets IP address

4. TCP connection starts

5. TLS handshake happens

6. HTTP request is sent

DNS is the first domino in every web request.

If DNS fails:

• Nothing else works

Why DNS Knowledge Matters for System Design

Understanding DNS helps you:

• Debug production issues

• Design highly available systems

• Understand load balancers and CDNs

• Configure custom domains correctly

• Reason about latency and caching

DNS is not “networking trivia”.
It’s core infrastructure.

The Mental Model to Keep

Remember this flow:

Domain Name
   ↓
Recursive Resolver
   ↓
Root Server
   ↓
TLD Server
   ↓
Authoritative Server
   ↓
IP Address

DNS is not magic.
It’s a well-designed, layered lookup system.

Final Thoughts

Most developers use DNS every day without understanding it.

But once you see how resolution actually works:

• Errors make sense

• Outputs stop looking scary

• System design decisions become clearer

DNS is the quiet backbone of the internet —
and now you know how it works.