How DNS Resolution Works: From Domain Name to IP Address
Introduction: DNS as the Internet’s Phonebook
When you type google.com in your browser, your computer does not understand that name. Computers only understand numbers called IP addresses, like 142.250.190.14.
Humans like names. Computers need numbers. DNS exists to connect the two.
DNS (Domain Name System) works like the internet’s phonebook. Just like a phonebook maps a person’s name to a phone number, DNS maps a website name to its IP address. Without DNS, you would have to remember numbers for every website you visit.
Every time you open a website, DNS quietly finds the correct IP address so your request reaches the right server. This process is called name resolution, and it happens automatically in the background.
In this blog, we’ll break down how DNS resolution works step by step, using the dig command to see what really happens when you look up google.com.
Why Name Resolution Exists (The Problem DNS Solves)
Computers do not understand website names. They only understand IP addresses, which are numbers.
Humans, on the other hand, cannot easily remember numbers.
This creates a problem:
Humans want to use names like
google.comComputers need numbers like
142.250.190.14
Name resolution exists to fix this problem. DNS translates domain names into IP addresses so both humans and computers can work together.
DNS also adds flexibility. A website’s IP address can change, but the domain name can stay the same. Users never notice the change.
Without DNS, using the internet would be slow, confusing, and painful.
What Is the dig Command and Why Engineers Use It
dig is a simple command-line tool used to check DNS records.
Browsers hide DNS details. dig shows them.
With dig, you can:
Ask DNS questions directly
See which servers answer
Understand how name resolution works step by step
Engineers use dig to:
Debug DNS issues
Learn how DNS is structured
Trace how a domain is resolved
In this blog, we’ll use dig not for debugging, but to see DNS layers clearly—from root servers to the final IP address.
Understanding dig . NS — Root Name Servers
The dot (.) means the root of DNS. It is the starting point of every DNS lookup.
When you run:
dig . NS
you are asking: “Who controls the top of the DNS system?”
The answer is a list of root name servers.
Root servers do not know IP addresses for websites. Their only job is to tell you:
Which servers handle
.comWhich handle
.orgWhich handle
.net
Think of root servers as a directory of directories. They point you to the next level, not the final answer.
This is the first step in DNS resolution.
Understanding dig com NS — TLD Name Servers
After the root, the next level is the TLD (Top-Level Domain). For google.com, the TLD is .com.
When you run:
dig com NS
you are asking: “Who manages all .com domains?”
The answer is a list of .com name servers.
These servers do not know the IP address of google.com. Their job is only to say:
- which servers are responsible for
google.com
Think of TLD servers as a middle layer. They guide you closer to the final owner.
This is the second step in DNS resolution.
Understanding dig google.com NS — Authoritative Name Servers
Now we reach the authoritative level.
When you run:
dig google.com NS
you are asking: “Who is responsible for google.com?”
The answer is a list of authoritative name servers.
These servers are owned by Google (or its DNS provider). They store the real DNS records for google.com.
Authoritative servers know:
IP addresses
mail servers
other DNS records
This is the last stop before getting the final answer.
Understanding dig google.com — Full DNS Resolution Flow
Now we ask DNS the final question.
When you run:
dig google.com
you are asking: “What is the IP address of google.com?”
Behind the scenes, DNS follows these steps:
Ask the root servers
Go to the .com TLD servers
Reach the authoritative servers
Get the IP address
dig may show only the final answer, but this full path happens every time.
This layered process makes DNS:
fast
reliable
scalable
This is how a name becomes an IP address.
How Recursive Resolvers Do This for Your Browser
Your browser does not talk to root or TLD servers directly.
It asks a recursive resolver (usually from your ISP or DNS provider).
The resolver:
talks to root servers
then TLD servers
then authoritative servers
gets the IP address
sends it back to your browser
Your browser only sees the final IP, not the steps.
Resolvers also cache results. This makes future requests faster.
DNS feels instant because resolvers do the hard work for you.
Connecting DNS Resolution to a Real Browser Request
When you type google.com in your browser, DNS is the first step.
The browser:
asks the recursive resolver for the IP
gets the IP address
opens a connection to that IP
sends the HTTP request
Without DNS, the browser would not know where to send the request.
DNS always runs before HTTP, HTTPS, or APIs.
So every page load starts with DNS—even if you never notice it.
Wrap-up: DNS Resolution as a Layered System
DNS works in layers, not in one step.
Root servers point to TLD servers
TLD servers point to authoritative servers
Authoritative servers give the final answer
Each layer has one clear job. This makes DNS simple, fast, and scalable.
Tools like dig help us see this process clearly.
Once you understand this flow, DNS stops feeling magical and starts feeling like a clean system design.
