How DNS Resolution Works

When we type google.com in a browser, we expect the website to load instantly. But behind this simple action is a well-structured system that translates human-friendly names into machine-friendly IP addresses. This system is called DNS, and understanding how it works is essential for anyone interested in networking, backend systems, or system design.

In this blog, I’ll explain how DNS resolution works step by step, using the dig command to build a clear mental model—from root servers all the way to loading a website in your browser.

---

1. What is DNS and Why Name Resolution Exists

DNS (Domain Name System) is often called the internet’s phonebook.

• We Humans remember names like google.com

• But Computers communicate using IP addresses like 142.250.182.14

DNS exists to map domain names to IP addresses so that humans don’t have to remember numbers. Without DNS, we would need to type IP addresses directly into browsers, which is impractical and error-prone.

---

2. What is the dig Command and When It Is Used

dig (Domain Information Groper) is a DNS diagnostic and debugging tool.

It is used to:

• Inspect how DNS resolution happens

• Query DNS records directly

• Troubleshoot DNS issues

• Understand which name servers are involved

Example:

- dig google.com

---

3. Understanding dig . NS and Root Name Servers

Let’s start at the very top of the DNS hierarchy.

-dig . NS

This command asks:

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

What does this mean?

• . represents the DNS root

• Root name servers don’t know IPs of websites

• They only know which servers handle each TLD (.com, .org, .in, etc.)

Key idea:

The root server is the first step in translating human readable host names into IP addresses.

They answer questions like:

“For .com, go ask these TLD name servers.”

---

4. Understanding dig com NS and TLD Name Servers

Next layer:

-dig com NS

This asks:

“Which name servers are responsible for the .com domain?”

What happens here?

• Root servers point us to .com TLD servers

• TLD servers manage all .com domains

• They don’t store IP addresses of websites

• They only know who the authoritative servers are

Key idea:

TLD servers are directory managers for domains under them

They say:

“For google.com, ask these authoritative name servers.”

---

5. Understanding dig google.com NS and Authoritative Name Servers

Now we query the domain itself:

-dig google.com NS

This returns authoritative name servers for google.com.

What are authoritative name servers?

• They store actual DNS records

• A, AAAA, MX, CNAME, etc.

• They give the final answer

For example:

• google.com → 142.250.x.x

Why NS records matter

NS (Name Server) records define:

• Who controls the domain’s DNS

• Where the final truth lives

Without correct NS records, DNS resolution breaks.

---

6. Understanding dig google.com and the Full DNS Resolution Flow

Now let’s do the full query:

-dig google.com

This returns an A record (IPv4 address).

But here’s the important part:

dig vs browser behavior

• dig (by default) asks a recursive resolver

• The resolver performs all steps internally:

  1. Ask root servers

  2. Ask TLD servers

  3. Ask authoritative servers

  4. Cache the result

---

7. How Recursive Resolvers Work Behind the Scenes

Recursive resolvers (like those run by ISPs or public DNS services) are the real workers.

They:

• Perform the entire DNS lookup chain

• Cache results for performance

• Reduce load on root and TLD servers

Why caching matters

• Faster browsing

• Lower latency

• Massive scalability of the internet

Without recursive caching, DNS would be slow and overloaded.

---

8. Connecting dig google.com to Real-World Browser Requests

When you open a browser and type:

-https://google.com

This is what happens:

1. Browser asks OS for IP

2. OS asks recursive DNS resolver

3. Resolver returns IP (often from cache)

4. Browser opens TCP connection to IP

5. HTTPS request is sent

6. Google responds with the webpage

DNS is the first and mandatory step before any HTTP or HTTPS communication.

---

Conclusion :

DNS is a distributed, hierarchical, and highly scalable system.

• Root servers → entry points

• TLD servers → domain directories

• Authoritative servers → source of truth

• Recursive resolvers → performance backbone

Using dig helps us see the layers clearly, instead of treating DNS as a black box. This understanding is extremely useful when working with backend systems, cloud deployments, load balancers, CDNs, and production debugging.