Prerequisites: Basic familiarity with the command line (optional but helpful).
Audience: Developers who know that DNS works, but not how it works.
The Great Human-Computer Disconnect
Here is the fundamental problem of the internet:
- Humans remember names. (
google.com,hashnode.com,twitter.com) - Computers only know numbers. (
142.250.193.206,104.22.4.1)
If you want to visit Google, you type google.com. But your browser has no idea where that is. It needs the IP address.
This bridging of the gap—turning a human name into a computer address—is called DNS Resolution (Domain Name System).
Most tutorials describe DNS as "The Phonebook of the Internet."
You look up a name, you find a number. Simple, right?
Wrong.
That analogy is too simple. A phonebook is a single book with every number in the world. If DNS worked like that, it would be a file with billions of lines that every computer would have to download every day. It would be impossible to maintain.
The Reality: DNS is not a Phonebook. DNS is a distributed Hierarchy.
It’s more like a Global Corporate Bureaucracy. No single person knows everyone's number. But everyone knows who to ask next.
Today, we are going to manually perform the job of your browser. We are going to trace a request step-by-step across the world to find out exactly how google.com becomes an IP address.
The Tool: Meet dig
To see this invisible conversation, we need a tool. We will use dig (Domain Information Groper).
Think of dig as an X-Ray machine for DNS. It lets us ask the questions your computer asks silently in the background.
Open your terminal (Git Bash or Mac/Linux Terminal) and type:
dig google.com
You'll get a big scary block of text. Don't panic. We are going to ignore the auto-magic and do it manually, layer by layer.
The Tree Principle: Understanding the Hierarchy
DNS is structured like an upside-down tree.
┌─────────────────────────────────────────────────────────────────────────────┐
│ DNS HIERARCHY PYRAMID │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────┐
│ ROOT │ ← "." (the invisible dot)
│ SERVERS │ 13 clusters worldwide
└──────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ .com │ │ .org │ │ .net │
│ TLD │ │ TLD │ │ TLD │ ← Top-Level Domain
└──────┬──────┘ └─────────────┘ └─────────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ google │ │ amazon │ │ github │ ← Authoritative servers
│ .com │ │ .com │ │ .com │ (owned by each company)
└──────────┘ └──────────┘ └──────────┘
Do you notice something weird?
Technically, when you type google.com, you are actually typing:
google.com. (Notice the dot at the end!)
That hidden dot at the end represents the Root. That is where our journey begins.
The Walkthrough: Resolving google.com Manually
Imagine we are a "Recursive Resolver" (like the server at your ISP). We know NOTHING except where the Root is.
Our mission: Find the IP of google.com.
Step 1: Asking the Wise Elders (The Root Servers)
We don't know where google.com is. But we know where the Root Servers (.) are. These are the 13 logical servers that oversee the entire internet.
Let's ask them: "Hey, do you know where google.com is?"
dig . NS
-
.= The Root -
NS= Name Server (Who is the boss here?)
The Answer:
The Root servers will tell you: "I don't know who 'google' is. But I know who manages all the .com websites. Go talk to the .com servers."
Step 2: Asking the Middle Managers (The TLD Servers)
Okay, we have a lead. We need to talk to the servers that manage .com. These are called Top Level Domain (TLD) Servers.
Let's ask them: "Hey .com servers, do you know where google.com is?"
dig com. NS
The Answer:
The .com servers (run by a company called Verisign) will say: "I don't know the specific IP for Google. I have millions of dot-coms! But, I have the address of Google's specific Name Servers. Go talk to them."
They hand us the address of ns1.google.com.
Step 3: Asking the Owner (Authoritative Name Servers)
Now we are getting close. We have been directed to Google's own personal name servers. These are the Authoritative Name Servers. They are the final authority on everything inside the Google empire.
Let's ask them: "Hey Google Name Server, surely YOU know where google.com is?"
dig google.com. NS
The Answer:
Google's server says: "Yes, I am the boss of Google.com. What do you want?"
Step 4: The Final Question (The A Record)
Now that we have the boss on the line, we ask for the actual address.
"I want the Address (A Record) for google.com."
dig @ns1.google.com google.com A
(Note: roughly simulating the request to the specific nameserver)
The Answer:
google.com. 300 IN A 142.250.193.206
BOOM. We found it. 142.250.193.206.
Diagram: dig Commands Mapped to DNS Stages
┌─────────────────────────────────────────────────────────────────────────────┐
│ dig COMMANDS ↔ DNS LOOKUP STAGES │
└─────────────────────────────────────────────────────────────────────────────┘
DNS HIERARCHY dig COMMAND
───────────── ─────────────
ROOT (.) dig . NS
│ └─► Returns: a.root-servers.net
│
▼
TLD (.com) dig com NS
│ └─► Returns: a.gtld-servers.net
│
▼
AUTHORITATIVE dig google.com NS
(google.com) └─► Returns: ns1.google.com
│
│
▼
FINAL ANSWER dig google.com
(IP Address) └─► Returns: 142.250.193.46
4. The Full Flow Visualization
Let's recap what just happened. This is the Resolver Dance:
┌─────────────────────────────────────────────────────────────────────────────┐
│ COMPLETE DNS RESOLUTION FLOW FOR google.com │
└─────────────────────────────────────────────────────────────────────────────┘
YOU RECURSIVE ROOT TLD GOOGLE
(Browser) RESOLVER SERVERS (.com) (Auth)
│ │ │ │ │
│ "google.com?" │ │ │ │
│────────────────────►│ │ │ │
│ │ │ │ │
│ │ "Who has .com?" │ │ │
│ │────────────────────►│ │ │
│ │ │ │ │
│ │ "Ask a.gtld-servers.net" │ │
│ │◄────────────────────│ │ │
│ │ │ │ │
│ │ "Who has google.com?" │ │
│ │──────────────────────────────────►│ │
│ │ │ │
│ │ "Ask ns1.google.com" │ │
│ │◄──────────────────────────────────│ │
│ │ │ │
│ │ "What's the IP of google.com?" │ │
│ │─────────────────────────────────────────────────►│
│ │ │
│ │ "142.250.193.46" │
│ │◄─────────────────────────────────────────────────│
│ │ │
│ "142.250.193.46" │ │
│◄────────────────────│ │
│ │ │
TOTAL: 4 queries behind the scenes for 1 domain lookup!
Why don't we see this every time?
If your browser did this Recursion (asking step-by-step) for every single image and file, the internet would be painfully slow.
This is why we have Caching.
- Your Browser caches the IP for a few minutes.
- Your OS (Windows/Mac) caches it.
- Your Router caches it.
- Your ISP caches it.
When you type google.com, your computer likely remembers the answer from 5 minutes ago and skips the entire journey. You only see this "dance" when the cache expires (TTL - Time To Live).
Summary
Next time you see a "DNS Resolution Error" in Chrome, you know exactly what failed.
It means your computer shouted into the void, asked the Root, asked the TLD, or asked the Authoritative server... and somewhere along that chain, nobody answered.
We typically treat dig and DNS as boring settings to configure. But under the hood, it's a beautifully organized, decentralized relay race that keeps the internet human-friendly.
Glossary for the Road:
- Root (.): The start of the hierarchy.
- TLD (.com, .org): The category managers.
- Authoritative Server: The owner who knows the final answer.
- Recursive Resolver: The servant (ISP) that runs around asking these questions for you.
- A Record: The IPv4 Address (The destination).
- NS Record: Name Server (Who manages this zone?).
Top comments (0)