Skip to main content

Command Palette

Search for a command to run...

How DNS Resolution Works

Published
4 min read
How DNS Resolution Works

DNS: the internet’s phonebook (quick recap)

The internet runs on numbers.
Humans remember names.

DNS (Domain Name System) exists to solve this gap.

When you type google.com in a browser, DNS helps translate that name into an IP address so your computer knows where to connect.

In simple terms:

DNS is the internet’s phonebook that helps computers find each other.

But how does this lookup actually happen?
That’s what DNS resolution is all about.


Why name resolution exists

Computers communicate using IP addresses like:

142.250.195.46

Humans prefer names like:

google.com

Name resolution is the process of converting:

Domain name → IP address

Without DNS resolution:

  • Browsers wouldn’t know where to connect

  • APIs wouldn’t work

  • Emails wouldn’t be delivered


Introducing dig: a DNS inspection tool

dig stands for Domain Information Groper.

It is a command-line tool used to:

  • Inspect DNS records

  • Debug DNS issues

  • Understand how DNS resolution works

Think of dig as:

A way to ask DNS questions and see raw answers.

Unlike browsers, dig shows you exactly what DNS servers respond with.


DNS resolution happens in layers

DNS is not one big database.
It is a hierarchy.

Resolution happens step by step:

Root → TLD → Authoritative → IP Address

Let’s walk through each layer using dig.


Step 1: Root name servers (dig . NS)

Run this command:

dig . NS

What this means:

  • . represents the DNS root

  • You are asking: “Who manages the root of DNS?”

What the root servers do

Root name servers:

  • Don’t know IP addresses of websites

  • Only know who manages each TLD (.com, .org, .net, etc.)

Think of root servers as:

The master directory that knows where top-level domains live.


Step 2: TLD name servers (dig com NS)

Now ask about .com:

dig com NS

What’s happening here:

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

What TLD servers do

TLD name servers:

  • Don’t know website IPs

  • Know which authoritative servers manage each domain under them

Analogy:

  • Root = country

  • TLD = city

  • Domain = street


Step 3: Authoritative name servers (dig google.com NS)

Next, ask about google.com:

dig google.com NS

This tells you:

  • Which name servers are authoritative for google.com

Why authoritative servers matter

Authoritative servers:

  • Store the real DNS records

  • Provide final answers

  • Are controlled by the domain owner

If DNS were a company:

  • Root and TLD guide you

  • Authoritative servers give the final decision


Step 4: Full resolution (dig google.com)

Now run:

dig google.com

This command:

  • Triggers the entire resolution flow

  • Returns the final IP address

Behind the scenes, the resolver:

  1. Asks root servers

  2. Asks TLD servers

  3. Asks authoritative servers

  4. Gets the IP address

All in milliseconds.


What NS records really represent

NS (Name Server) records answer one question:

“Who is responsible for answering DNS questions for this domain?”

They:

  • Delegate authority

  • Enable scalability

  • Prevent a single point of failure

Without NS records, DNS would not work as a distributed system.


Recursive resolvers: the invisible worker

When you use dig, your system often talks to a recursive resolver (ISP, Google DNS, Cloudflare).

Recursive resolvers:

  • Perform the full DNS lookup for you

  • Cache results

  • Speed up future requests

Your browser never talks directly to root servers.
The resolver does that on your behalf.


Connecting dig google.com to a browser request

When you type google.com in your browser:

  1. Browser asks OS

  2. OS asks recursive resolver

  3. Resolver performs DNS resolution

  4. IP address is returned

  5. Browser connects to the server

dig lets you see this process without browser shortcuts or caching tricks.


DNS resolution from a system-design perspective

DNS resolution is:

  • Distributed

  • Fault-tolerant

  • Cached

  • Hierarchical

This design allows:

  • Billions of queries per day

  • No central database

  • Fast global resolution

Understanding this flow is critical for:

  • System design interviews

  • Debugging production issues

  • Cloud and DevOps work


Final thoughts

DNS resolution may look complex, but it follows a clear path:

Root → TLD → Authoritative → Answer

Tools like dig help you see what normally stays hidden.

Once you understand this flow, DNS stops being mysterious and starts making perfect sense.

And that’s a big win for any developer 🚀