Demystifying DNS Resolution

Every time you type a website like google.com into your browser, something magical—but very real—happens behind the scenes.

Your browser doesn’t understand names.
The internet runs on numbers.

So how does google.com magically turn into an IP address like 142.250.190.142?

That invisible translation layer is called DNS (Domain Name System).

In this article, we’ll go from zero → solid intermediate understanding, and by the end, you’ll be able to:

• Explain DNS confidently in interviews

• Visualize DNS resolution as a layered system

• Use dig like a pro to debug real DNS issues

1. What Is DNS? The Internet’s Phonebook

DNS is often called the Internet’s Phonebook.

Just like:

• Name → Phone Number (in a phonebook)

• Domain Name → IP Address (in DNS)

Why DNS Exists

Imagine if you had to remember this instead of google.com: 142.250.190.142 it is Not fun. Not scalable. Not human-friendly.

DNS solves this by translating: google.com → IP address

Your browser, servers, APIs, and cloud infrastructure all rely on DNS to talk to each other.

Without DNS, the modern internet simply doesn’t work.

2. DNS as a Distributed System (Not a Single Server)

A common beginner mistake is thinking:

“There must be one big DNS server somewhere.”

Nope !!!

DNS is:

• Distributed

• Hierarchical

• Fault-tolerant

• Globally scalable

This is what allows billions of DNS queries per second.

3. DNS Hierarchy: Root → TLD → Authoritative

DNS is structured like an inverted tree.

Root (.) 

 └──> TLD (.com, .org)

      └──> Domain (google.com)

           └──> Subdomain (mail.google.com)

The 4 Key DNS Players

Layer	Server Type	Responsibility
1	Recursive Resolver	Talks to DNS on your behalf
2	Root Name Server	Knows where TLD servers are
3	TLD Name Server	Knows where domain servers are
4	Authoritative Server	Knows the final IP

Your browser never talks to all of them directly. The recursive resolver does the hard work.

4. Meet dig: Your DNS x-ray tool

dig stands for Domain Information Groper.

It lets you:

• Inspect DNS records

• Trace DNS resolution

• Debug production DNS issues

• Understand what browsers do silently

Why dig over nslookup?

• More accurate

• More detailed

• Industry standard

5. Understanding DNS Step by Step Using dig

Let’s build the mental model layer by layer.

5.1 dig . NS → Root Name Servers

dig . NS

What this means

• . represents the DNS root

• NS asks: Who are the name servers?

What you learn

• There are 13 logical root servers (A–M)

• They don’t store IPs for websites

• They only know who handles each TLD

Root servers are managed globally and distributed using Anycast, so they’re fast and resilient.

5.2 dig com NS → TLD Name Servers

dig com NS

What happens

• You’re asking: Who manages .com domains?

What you learn

• .com is handled by dedicated TLD name servers

• These servers don’t know google.com’s IP

• They only know which servers are authoritative for google.com

This separation is what makes DNS scalable.

5.3 dig google.com NS → Authoritative Name Servers

dig google.com NS

Meaning

• You’re asking: Who is the final authority for google.com?

Output tells you

• Google’s authoritative servers (like ns1.google.com)

• These servers contain the source of truth

Only authoritative servers can give the final answer.

5.4 dig google.com → Final Resolution

dig google.com

This is the full resolution result.

What happens behind the scenes

1. Browser checks local cache

2. OS cache is checked

3. Recursive resolver is queried

4. Resolver asks:

   • Root → TLD → Authoritative

5. Final IP is returned

6. Result is cached using TTL

This entire process usually finishes in milliseconds.

6. Watching DNS in Action: dig +trace

dig google.com +trace

This is the most important command for learning DNS.

What +trace does

• Starts at the root

• Manually walks down the hierarchy

• Ignores cache

• Shows every delegation step

Output shows:

1. Root servers responding

2. .com TLD servers responding

3. Google authoritative servers responding

4. Final IP address

This is DNS resolution exposed in raw form.

7. How Browsers Really Use DNS

Browsers don’t talk to root or TLD servers directly.

They:

• Ask a recursive resolver (ISP, Cloudflare 1.1.1.1, Google 8.8.8.8)

• Resolver does iterative lookups

• Results are cached aggressively

Why caching matters

• Faster page loads

• Less global DNS traffic

• Controlled by TTL (Time To Live)

8. Practical DNS Troubleshooting with dig

Website not loading?

dig example.com

Check authoritative servers

dig example.com NS

Trace where it breaks

dig example.com +trace

Compare DNS providers

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

Check email issues

dig example.com MX

Reverse lookup (IP → domain)

dig -x 93.184.216.34

9. DNS from a System Design Perspective

Why DNS is a masterclass in system design:

• No single point of failure

• Clear separation of responsibility

• Heavy caching

• Global distribution using Anycast

• Designed to survive partial outages

That’s why even massive outages rarely take DNS completely down.

10. Mental Model to Remember Forever

Think of DNS like this: