How DNS Resolution Works

Before we go full nerd mode, quick question
When you type google.com in your browser how does your computer know where to go

Servers do not understand names. They speak IP addresses.
Humans do not remember IP addresses. We speak names.

So we needed a translator.
That translator is DNS.

Think of DNS like the internet’s phonebook. You know the name, it gives you the number.

But today we are not just using the phonebook.
We are opening it up and seeing how it is structured using a very underrated command line tool called dig.

What is DNS and Why Name Resolution Exists

Imagine if every time you wanted to visit a site, you had to type this

142.250.183.46

instead of this

google.com

Yeah no thanks.

DNS Domain Name System exists to

• Map domain names to IP addresses

• Keep this mapping distributed and not stored in one giant server

• Make the internet scalable and fault tolerant

This process is called name resolution which means converting a domain name into an IP address.

And this resolution happens in layers, not in one step.

We will walk that path step by step.

Meet dig The DNS X Ray Machine

dig stands for Domain Information Groper.

It is basically a tool that says
Show me what DNS knows about this domain.

You use dig when

• DNS is not resolving

• You want to debug domain setup

• You want to understand DNS flow

• You want to inspect records directly

Basic usage

dig google.com

But the real fun starts when we ask more specific questions.

DNS Resolution Happens in Layers

DNS is not one server. It is a hierarchy.

Root → TLD → Authoritative → Final Answer

We are going to walk this chain manually using dig and build a mental model as we go.

Step 1 Root Name Servers

dig . NS

Run this command

dig . NS

This asks
Who are the name servers for the root of the internet

You will see a list like

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

These are the top of the DNS hierarchy.

They do not know IPs for websites.

But they know who to ask next.

Their job is direction, not answers. Think reception desk, not the manager.

Step 2 TLD Name Servers

dig com NS

Now we go one level down

dig com NS

We are asking
Who manages dot com domains

You will get TLD Top Level Domain name servers.

They do not know google’s IP either, but they know who is authoritative for google.com.

Again directions, not final answers.

Step 3 Authoritative Name Servers

dig google.com NS

Now run

dig google.com NS

Now we are asking
Who is the official source of truth for google.com

You will see Google’s name servers.

These are the authoritative servers.

This is where

• Final DNS records live

• IP mappings live

• MX records live

• TXT records live

• The real answers live

If DNS had bosses, this is them.

What NS Records Actually Mean

NS means Name Server records.

They tell which servers are responsible for answering DNS queries for a domain.

Why this matters

• Delegation

• Scalability

• Distributed control

• Faster lookups globally

Without NS records, DNS would be chaos.

They are the routing table of the DNS world.

Step 4 Full Resolution

dig google.com

Now the full query

dig google.com

This gives

• Final IP address

• TTL which tells how long the cache can live

• Answer section

• Authority section

• Additional records

This is what your browser ultimately needs to connect.

What Actually Happens When You Open a Browser

When you type google.com

1 Browser checks its cache
2 Operating system checks its cache
3 Recursive resolver checks its cache
4 If not found it starts asking step by step

Root → TLD → Authoritative → Final IP

It stitches together the path using NS records at each step.

You normally never see this process, but dig lets you watch it directly.

Recursive Resolvers The Silent Workers

You usually do not talk to root servers directly.

Your system talks to a recursive resolver that

• Does all the asking

• Follows the DNS chain

• Caches answers

• Returns the final IP

That is why DNS usually feels instant. Someone already did the lookup and cached it.

Connecting This to Real System Design

This layered DNS model gives

• Global scalability

• No single point of failure

• Distributed authority

• Fast caching

• Delegated ownership

It behaves like a well designed distributed system.

Each layer has one job

• Root knows TLD servers

• TLD knows domain authorities

• Authoritative servers know actual records

Clean separation of concerns.

Mental Model to Remember

If DNS were a company

• Root is corporate headquarters

• TLD is regional offices

• Authoritative servers are department heads

• Records are the actual data

And dig is you walking in and asking each level directly.

Run these commands once yourself and DNS will stop feeling like magic and start feeling like a system you can reason about.