DEV Community

Harsh
Harsh

Posted on

How DNS Resolution Works

When you type google.com into your browser and press Enter, you’re not actually connecting to “google.com”.

You’re connecting to an IP address like 142.250.77.46.

dns related meme

So the real question is:

How does the internet convert human-friendly names into machine-friendly IPs?

That system is called DNS (Domain Name System) often described as the internet’s phonebook.

This article walks step-by-step through:

  • What DNS is and why it exists
  • How the dig command helps us inspect DNS
  • Root, TLD, and authoritative name servers
  • The full DNS resolution flow for google.com
  • How all of this connects to real browser requests

And we’ll build everything logically using real dig commands.


What is DNS and why name resolution exists

Computers don’t understand domain names.

They communicate using IP addresses.

But humans don’t want to remember this: 142.250.77.46

So DNS exists to answer one simple question:

“What is the IP address of this domain name?”

Example: google.com → 142.250.77.46

DNS provides:

  • Human-readable names
  • Decentralized global database
  • Scalable and fault-tolerant name resolution

Without DNS, the modern web wouldn’t be usable.

meme reference


What is the dig command and when it is used

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

It allows you to:

  • Query DNS servers directly
  • Inspect DNS records (A, NS, MX, TXT, etc.)
  • Debug DNS issues
  • Understand how name resolution actually works

Example:

dig google.com
Enter fullscreen mode Exit fullscreen mode

This doesn’t just give you an IP, it shows the entire DNS answer structure.

DNS works in layers

DNS is hierarchical

dns hierarchical structure

Each layer doesn’t know the final answer.

It only knows who to ask next.


Understanding dig . NS → Root name servers

Let’s start at the very top.

dig . NS
Enter fullscreen mode Exit fullscreen mode

This asks:

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

You’ll see servers like:

a.root-servers.net  
b.root-servers.net  
c.root-servers.net  
...
Enter fullscreen mode Exit fullscreen mode

These are root name servers.

They do NOT know the IP of google.com.

They only know:

“Who manages .com?”

“Who manages .org?”

Their job is to point you to TLD name servers.


Understanding dig com NS → TLD name servers

Now let’s move one level down.

dig com NS
Enter fullscreen mode Exit fullscreen mode

This asks:

“Who manages the .com domain?”

The response returns name servers operated by companies like Verisign.

These TLD servers don’t know Google’s IP either.

They only know:

“Who is authoritative for google.com?”

So they return the authoritative name servers for google.com.


Understanding dig google.com NS → Authoritative name servers

dig google.com NS
Enter fullscreen mode Exit fullscreen mode

This returns servers like:

ns1.google.com  
ns2.google.com  
ns3.google.com  
ns4.google.com  
Enter fullscreen mode Exit fullscreen mode

These are authoritative name servers.

This is where truth lives.

They store the real DNS records:

  • A (IP address)
  • MX (mail servers)
  • TXT (verification, SPF, etc.)

If you want the actual IP of google.com, this is where it comes from.


Understanding dig google.com → Full DNS resolution

dig google.com
Enter fullscreen mode Exit fullscreen mode

You’ll see something like:

google.com.   300   IN   A   142.250.77.46
Enter fullscreen mode Exit fullscreen mode

Behind the scenes (if uncached), the resolver performed:

  • Ask root → who handles .com?
  • Ask TLD → who handles google.com?
  • Ask authoritative → what is the IP?

Your system’s recursive resolver did all this work for you.


What NS records really represent

NS records don’t map names to IPs.

They map names to name servers responsible for that zone.

Example:

google.com → ns1.google.com
Enter fullscreen mode Exit fullscreen mode

They define ownership and delegation.

This is how DNS stays:

  • Decentralized
  • Scalable
  • Company-controlled

Google controls its DNS.
You control yours.

The root doesn’t control Google.

What your recursive resolver actually does

Your computer usually talks to:

  • ISP DNS
  • Router DNS
  • Public DNS (8.8.8.8, 1.1.1.1)

These are recursive resolvers.

They You ask one question:

  • Query root servers
  • Query TLD servers
  • Query authoritative servers
  • Cache results
  • Protect you from complexity

They perform the entire DNS walk.


How this connects to real browser requests

When you visit:

https://www.google.com
Enter fullscreen mode Exit fullscreen mode

Your browser:

  • Asks OS for IP
  • OS asks recursive resolver
  • Resolver walks DNS
  • Gets IP
  • Browser opens TCP connection
  • TLS handshake starts
  • HTTP request is sent

Step-by-step DNS resolution
No DNS = No website.
Every API call, cloud service, CDN, and microservice starts with DNS.


Mapping dig to DNS lookup stages

| Command           | What it represents    |
| ----------------- | --------------------- |
| dig . NS          | Root name servers     |
| dig com NS        | TLD name servers      |
| dig google.com NS | Authoritative servers |
| dig google.com    | Final resolution      |
Enter fullscreen mode Exit fullscreen mode

Each command reveals one layer of the system.

Top comments (0)