How DNS Resolution Works ( A Practical, Layer-by-Layer Story)

Think of DNS as the internet’s phonebook. Humans remember names like google.com, but computers talk in IP addresses like 142.250.72.14. DNS exists to bridge that gap turning readable names into routable addresses, billions of times a day, in milliseconds.

As engineers, DNS is one of those systems that just works until it doesn’t. And when it breaks, knowing how resolution actually works becomes priceless.

Let’s build that understanding step by step.

---

What Is DNS and Why Name Resolution Exists

At its core, DNS (Domain Name System) is a globally distributed, hierarchical database.

Why hierarchical?
Because no single system could realistically store or serve the entire internet’s naming data. Instead, DNS is split into layers of responsibility, each answering only what it knows.

This design gives us:

1. Scalability (no central bottleneck)

2. Fault isolation

3. Delegated ownership (Google controls google.com, not ICANN)

Introducing dig: Your DNS Debugging Microscope

dig (Domain Information Groper) is a diagnostic tool that lets you inspect DNS resolution, step by step.

When a browser makes a request, all this DNS work happens invisibly. dig lets us slow time down and watch the gears turn.

We’ll use it to query -

1. Root name servers

2. TLD name servers

3. authorotative name servers

dig . NS - Root Name Servers

dig . NS

This asks: “Who is responsible for the root of DNS?”

The response lists root name servers (a.root-servers.net, b.root-servers.net, etc.).

Key insight:

1. Root servers don’t know IPs for domains

2. They only know which servers handle each TLD (.com, .org, .net)

They are traffic directors, not data stores.

dig com NS - TLD Name Servers

dig com NS

Now we ask: “Who manages .com?”

These TLD (Top Level Domain) servers know -

1. Which authoritative servers are responsible for ggoogle.com

2. But not Google’s IP addresses themselves

Think of TLD servers as regional offices closer to the data, but still not the source of truth.

dig google.com NS - Authoritative Name Servers

dig google.com NS

This returns Google’s authoritative name servers.

Important concept -

1. NS records define delegation

2. They say: “These servers are the source of truth for this domain”

Authoritative servers are where real answers live -

1. A / AAAA records

2. MX records

3. TXT records

dig google.com - Full DNS Resolution

dig google.com

This is what your browser effectively triggers.

Behind the scenes, a recursive resolver (usually your ISP or public DNS like 8.8.8.8) does the work:

1. Ask root servers → Who handles .com?

2. Ask TLD servers → Who handles google.com?

3. Ask authoritative servers → What is the IP?

4. Cache the answer and return it to the client

Your browser just waits for the final IP.

Step by Step DNS Resolution for google.com

1. Browser asks the OS resolver

2. OS asks recursive resolver

3. Recursive resolver queries root servers

4. Root → TLD servers

5. TLD → authoritative servers

6. Authoritative → IP address

7. IP returned → TCP/TLS/HTTP begins

DNS finishes before your first HTTP byte is sent.

Why This Matters in System Design

1. DNS caching hides latency but introduces staleness

2. TTL tuning affects failover and resilience

3. Multi-region systems rely heavily on DNS-based routing

4. Outages often look like “the internet is broken” but are DNS misconfigurations

understanding DNS isn’t optional, it’s foundational.