How DNS Resolution Works: From Root Servers to Your Browser
Introduction: The Internet's Phonebook Problem
Imagine you want to call your friend, but you only know their name, not their phone number. You'd look them up in a phonebook (or contacts app today). The internet has the same problem:
You know: google.com
You need: 142.250.185.46 (IP address)
Why? Computers communicate using IP addresses, not names.
DNS (Domain Name System) is the internet's phonebook. It translates human-friendly names into computer-friendly IP addresses.
┌─────────────────────────────────────────────────────────────┐
│ WITHOUT DNS │
└─────────────────────────────────────────────────────────────┘
You: "I want to visit Google"
Computer: "What's Google?"
You: "Uh... it's at 142.250.185.46"
Computer: "Why didn't you just say so?"
Problem: Humans can't remember billions of IP addresses!
┌─────────────────────────────────────────────────────────────┐
│ WITH DNS │
└─────────────────────────────────────────────────────────────┘
You: "I want google.com"
DNS: "That's 142.250.185.46"
Computer: "Got it! Connecting..."
Solution: DNS does the translation automatically
Today, we'll explore how DNS resolution actually works by using the dig command to peek inside this critical internet infrastructure.
What is DNS and Why Name Resolution Exists
The Fundamental Problem
┌─────────────────────────────────────────────────────────────┐
│ WHY DNS EXISTS │
└─────────────────────────────────────────────────────────────┘
Computers need IP addresses:
├── IPv4: 192.168.1.1 (4 numbers, 0-255)
└── IPv6: 2001:0db8:85a3::8a2e:0370:7334 (even longer!)
Humans prefer names:
├── google.com
├── amazon.com
└── facebook.com
Someone needs to translate between them → DNS!
Real-World Analogy
Calling a friend:
├── You remember: "John Smith"
├── Phone needs: "+1-555-0123"
├── Contacts app: Does the translation
└── Call connects!
Visiting a website:
├── You remember: "google.com"
├── Computer needs: "142.250.185.46"
├── DNS: Does the translation
└── Page loads!
What DNS Provides
1. Name to IP Translation
google.com → 142.250.185.46
2. Distributed Database
No single server has all the answers
Information spread across millions of servers
3. Hierarchical System
Organized like a tree structure
Root → TLD → Domain → Subdomain
4. Caching
Remember recent answers to speed things up
What is the dig Command?
dig (Domain Information Groper) is a command-line tool for querying DNS servers.
Why Use dig?
Think of `dig` as a DNS detective tool:
Normal browser:
├── Asks DNS for google.com
├── Gets IP address
├── Loads page
└── You never see the DNS process
With `dig`:
├── You explicitly query DNS
├── See exactly what DNS returns
├── Inspect the resolution process
└── Understand what's happening behind the scenes
Basic dig Syntax
dig [domain] [query-type]
Examples:
dig google.com # Get IP address (A record)
dig google.com NS # Get name servers
dig google.com MX # Get mail servers
dig @8.8.8.8 google.com # Query specific DNS server
Installing dig
macOS/Linux: Usually pre-installed
Windows: Install BIND tools or use WSL
Alternative: nslookup (available on all platforms)
Understanding DNS Hierarchy
Before diving into dig commands, understand the DNS hierarchy:
┌─────────────────────────────────────────────────────────────┐
│ DNS HIERARCHY (TOP TO BOTTOM) │
└─────────────────────────────────────────────────────────────┘
Root Level (.)
↓
Top-Level Domain (TLD) (.com, .org, .net, .uk, etc.)
↓
Second-Level Domain (google, amazon, facebook)
↓
Subdomain (www, mail, api)
↓
Full domain: www.google.com
Visual representation:
. (Root)
|
┌──────────────┼──────────────┐
↓ ↓ ↓
.com .org .net
| | |
↓ ↓ ↓
google wikipedia example
|
↓
www
Breaking down: www.google.com.
www.google.com.
↑ ↑ ↑ ↑
│ │ │ └─ Root (usually invisible but technically there)
│ │ └──── TLD (Top-Level Domain)
│ └────────── Second-Level Domain (SLD)
└────────────── Subdomain
Full hierarchy: . → com → google → www
Understanding dig . NS – Root Name Servers
The root name servers are at the top of the DNS hierarchy.
Command
dig . NS
What This Asks
Question: "Who are the root name servers?"
Answer: List of 13 root server letters (a-m)
Sample Output
$ dig . NS
; <<>> DiG 9.10.6 <<>> . NS
;; ANSWER SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.
Breaking Down the Output
┌─────────────────────────────────────────────────────────────┐
│ UNDERSTANDING THE OUTPUT │
└─────────────────────────────────────────────────────────────┘
. Root zone
518400 TTL (Time To Live) in seconds = 6 days
IN Internet class
NS Name Server record type
a.root-servers.net. Name of the root server
What Are Root Servers?
Root servers are the starting point of DNS resolution:
├── There are 13 root server letters (a through m)
├── Each letter has hundreds of physical servers worldwide
├── Total: Thousands of actual servers for redundancy
└── They know where TLD servers (.com, .org, etc.) are
Think of them as the "information desk" at the top
Real-World Analogy
You walk into a massive library (the internet):
You: "Where can I find information about .com domains?"
Root servers: "Go to the .com section on the 5th floor"
Root servers don't know about specific books (domains)
They only know which floor (TLD servers) to send you to
Why 13 Root Servers?
Historical reason:
├── DNS responses must fit in 512 bytes (original limit)
├── 13 names fit within this limit
└── Each name (a-m) backed by hundreds of actual servers
Distributed globally:
├── Anycast routing (same IP, different physical servers)
├── Closest server responds to your request
└── High availability and redundancy
Understanding dig com NS – TLD Name Servers
TLD (Top-Level Domain) servers manage specific extensions like .com, .org, .net.
Command
dig com NS
What This Asks
Question: "Who are the name servers for the .com TLD?"
Answer: List of servers managing .com domains
Sample Output
$ dig com NS
; <<>> DiG 9.10.6 <<>> com NS
;; ANSWER SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
Breaking Down the Output
com. The .com TLD
172800 TTL = 2 days
IN Internet class
NS Name Server record
a.gtld-servers.net. Generic TLD server (managed by Verisign)
What Are TLD Servers?
TLD servers manage all domains under one extension:
├── .com servers know about: google.com, amazon.com, etc.
├── .org servers know about: wikipedia.org, mozilla.org, etc.
├── .net servers know about: example.net, etc.
└── Country codes: .uk, .de, .jp each have their own servers
They don't store website content
They only know which name servers manage each domain
Real-World Analogy
Continuing our library analogy:
You: "Where can I find books about 'google'?"
.com TLD server: "Google's books are managed by ns1.google.com"
"Go ask them for specific information"
TLD servers know which organization manages each domain
But they don't have the details themselves
How You Got Here
┌─────────────────────────────────────────────────────────────┐
│ DNS RESOLUTION PATH SO FAR │
└─────────────────────────────────────────────────────────────┘
Step 1: dig . NS
"Who are the root servers?"
Answer: a-m.root-servers.net
Step 2: dig com NS
"Who manages .com domains?"
Answer: a-m.gtld-servers.net
Next step: Find who manages a specific domain (e.g., google.com)
Understanding dig google.com NS – Authoritative Name Servers
Authoritative name servers are the final authority for a specific domain.
Command
dig google.com NS
What This Asks
Question: "Who are the authoritative name servers for google.com?"
Answer: The servers that Google controls for their domain
Sample Output
$ dig google.com NS
; <<>> DiG 9.10.6 <<>> google.com NS
;; ANSWER SECTION:
google.com. 21600 IN NS ns1.google.com.
google.com. 21600 IN NS ns2.google.com.
google.com. 21600 IN NS ns3.google.com.
google.com. 21600 IN NS ns4.google.com.
Breaking Down the Output
google.com. The domain we're asking about
21600 TTL = 6 hours
IN Internet class
NS Name Server record
ns1.google.com. Google's authoritative name server #1
What Are Authoritative Name Servers?
Authoritative servers have the final answer:
├── They store actual DNS records for the domain
├── A records (IP addresses)
├── MX records (mail servers)
├── CNAME records (aliases)
└── And more...
They are the "source of truth" for that domain
Real-World Analogy
Library analogy final step:
You: "I need the exact location of Google's homepage"
Google's authoritative server: "Here's the IP: 142.250.185.46"
These servers have the actual information you need
Not just pointers to other servers
DNS Resolution Path Complete
┌─────────────────────────────────────────────────────────────┐
│ COMPLETE DNS HIERARCHY FOR google.com │
└─────────────────────────────────────────────────────────────┘
Step 1: Root servers (.)
"Who manages .com?"
→ a-m.gtld-servers.net
Step 2: TLD servers (.com)
"Who manages google.com?"
→ ns1-4.google.com
Step 3: Authoritative servers (google.com)
"What's the IP for google.com?"
→ 142.250.185.46
Each level points to the next level
Until you reach the authoritative answer
Understanding dig google.com – Full DNS Resolution
Now let's get the actual IP address for google.com.
Command
dig google.com
What This Asks
Question: "What is the IP address of google.com?"
Answer: The A record (IPv4 address)
Sample Output
$ dig google.com
; <<>> DiG 9.10.6 <<>> google.com
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
;; AUTHORITY SECTION:
google.com. 21600 IN NS ns1.google.com.
google.com. 21600 IN NS ns2.google.com.
google.com. 21600 IN NS ns3.google.com.
google.com. 21600 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 21600 IN A 216.239.32.10
ns2.google.com. 21600 IN A 216.239.34.10
ns3.google.com. 21600 IN A 216.239.36.10
ns4.google.com. 21600 IN A 216.239.38.10
;; Query time: 45 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 31 10:30:00 UTC 2026
;; MSG SIZE rcvd: 272
Breaking Down Each Section
1. Question Section
;; QUESTION SECTION:
;google.com. IN A
Translation: "What is the A record (IPv4 address) for google.com?"
2. Answer Section
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
google.com. Domain being queried
300 TTL = 5 minutes (cache this answer for 5 minutes)
IN Internet class
A Record type (Address - IPv4)
142.250.185.46 The IP address! (This is what we wanted)
3. Authority Section
;; AUTHORITY SECTION:
google.com. 21600 IN NS ns1.google.com.
Shows which name servers are authoritative for google.com
Same as we saw in `dig google.com NS`
4. Additional Section
;; ADDITIONAL SECTION:
ns1.google.com. 21600 IN A 216.239.32.10
Helpful bonus: IP addresses of the authoritative name servers
So you don't need to look those up separately
5. Query Statistics
;; Query time: 45 msec Time it took to get answer
;; SERVER: 8.8.8.8#53 DNS server we queried (Google's DNS)
;; MSG SIZE rcvd: 272 Size of the response in bytes
The Complete DNS Resolution Flow
Let's trace what happens when your browser looks up google.com:
Step-by-Step Resolution
┌─────────────────────────────────────────────────────────────┐
│ COMPLETE DNS RESOLUTION PROCESS │
└─────────────────────────────────────────────────────────────┘
User types: google.com
↓
1. CHECK LOCAL CACHE
Browser/OS: "Do I already know google.com's IP?"
├─ If YES: Use cached IP (done!)
└─ If NO: Continue to step 2
2. ASK RECURSIVE RESOLVER
Computer → Recursive Resolver (e.g., 8.8.8.8)
"What's the IP for google.com?"
Recursive resolver checks its cache:
├─ If cached: Return answer (done!)
└─ If not: Continue to step 3
3. ASK ROOT NAME SERVER
Recursive Resolver → Root Server
"Where do I find .com domains?"
Root Server: "Ask a.gtld-servers.net (TLD server)"
4. ASK TLD NAME SERVER
Recursive Resolver → .com TLD Server
"Where do I find google.com?"
TLD Server: "Ask ns1.google.com (authoritative server)"
5. ASK AUTHORITATIVE NAME SERVER
Recursive Resolver → ns1.google.com
"What's the IP for google.com?"
Authoritative Server: "142.250.185.46"
6. RETURN ANSWER
Recursive Resolver → Your Computer
"google.com is at 142.250.185.46"
Also caches the answer for future requests
7. BROWSER CONNECTS
Browser → 142.250.185.46
TCP connection established
HTTP request sent
Page loads!
Visual Flow Diagram
┌─────────────────────────────────────────────────────────────┐
│ DNS RESOLUTION FLOW FOR google.com │
└─────────────────────────────────────────────────────────────┘
Your Computer
↓ (1) "What's google.com?"
Recursive Resolver (8.8.8.8)
↓ (2) "Who knows about .com?"
Root Name Server (a.root-servers.net)
↓ (3) "Ask the .com TLD server"
TLD Server (a.gtld-servers.net)
↓ (4) "Who manages google.com?"
← (5) "ns1.google.com does"
TLD Server
↓ (6) "What's google.com's IP?"
Authoritative Server (ns1.google.com)
↓ (7) "142.250.185.46"
← (8) Returns answer
Recursive Resolver
↓ (9) Returns to you + caches
Your Computer
↓ (10) Connects to IP
google.com loads!
Recursive vs Authoritative DNS Servers
Recursive Resolver
Role: Acts as a middleman, does the work for you
Characteristics:
├── Accepts queries from clients (your computer)
├── Performs full DNS resolution (queries multiple servers)
├── Caches results to speed up future queries
├── Examples: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)
Think of it as: Your personal assistant who researches for you
Authoritative Name Server
Role: Provides definitive answers for specific domains
Characteristics:
├── Stores actual DNS records for domains
├── Only answers for domains it manages
├── Doesn't query other servers
├── Examples: ns1.google.com, ns1.amazon.com
Think of it as: The original source of truth
Visual comparison:
┌─────────────────────────────────────────────────────────────┐
│ RECURSIVE vs AUTHORITATIVE │
└─────────────────────────────────────────────────────────────┘
RECURSIVE RESOLVER (8.8.8.8):
You: "What's google.com?"
Resolver: "I'll find out for you!"
[queries root, TLD, authoritative]
"It's 142.250.185.46"
AUTHORITATIVE SERVER (ns1.google.com):
You: "What's google.com?"
Authoritative: "142.250.185.46" (already knows)
You: "What's amazon.com?"
Authoritative: "I don't know, I only manage google.com"
TTL (Time To Live) and Caching
What is TTL?
TTL = How long to cache this DNS answer
Example:
google.com. 300 IN A 142.250.185.46
↑
300 seconds = 5 minutes
Meaning: Cache this answer for 5 minutes
After that, query again for fresh data
Why Caching Matters
┌─────────────────────────────────────────────────────────────┐
│ WITHOUT CACHING │
└─────────────────────────────────────────────────────────────┘
Visit google.com:
├── Full DNS resolution (4 queries)
├── Reload page: Full DNS resolution again
├── Visit 10 times: 40 DNS queries!
└── Time wasted: Seconds per page load
Servers overwhelmed, users wait
┌─────────────────────────────────────────────────────────────┐
│ WITH CACHING (TTL = 300 seconds) │
└─────────────────────────────────────────────────────────────┘
Visit google.com:
├── Full DNS resolution (4 queries)
├── Cache answer for 5 minutes
├── Reload 10 times: 0 additional DNS queries
└── Time saved: Instant page loads
Servers happy, users happy
TTL Trade-offs
Short TTL (e.g., 60 seconds):
✓ Changes propagate quickly
✓ Good for frequently updated records
✗ More DNS queries
✗ Higher server load
Long TTL (e.g., 86400 = 1 day):
✓ Fewer DNS queries
✓ Lower server load
✗ Changes take longer to propagate
✗ Bad for dynamic IPs
Common DNS Record Types
While we focused on A and NS records, here are other common types:
┌─────────────────────────────────────────────────────────────┐
│ DNS RECORD TYPES │
└─────────────────────────────────────────────────────────────┘
A IPv4 address
google.com → 142.250.185.46
AAAA IPv6 address
google.com → 2607:f8b0:4004:c07::65
CNAME Alias (canonical name)
www.example.com → example.com
MX Mail server
example.com → mail.example.com
NS Name server
google.com → ns1.google.com
TXT Text record (verification, SPF, DKIM)
example.com → "v=spf1 include:_spf.google.com ~all"
SOA Start of authority (zone information)
Administrative details about the domain
Querying Different Record Types
dig google.com A # IPv4 address
dig google.com AAAA # IPv6 address
dig google.com MX # Mail servers
dig google.com TXT # Text records
dig google.com NS # Name servers
dig google.com ANY # All records (not always supported)
Practical Examples with dig
Example 1: Trace Full Resolution Path
dig +trace google.com
What it does:
Shows every step of DNS resolution:
├── Queries root servers
├── Queries TLD servers
├── Queries authoritative servers
└── Shows complete path
Sample output (abbreviated):
. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
google.com. 21600 IN NS ns1.google.com.
google.com. 300 IN A 142.250.185.46
Example 2: Query Specific DNS Server
dig @8.8.8.8 google.com
What it does:
Queries Google's DNS server (8.8.8.8) specifically
Instead of your default DNS server
Example 3: Get Concise Answer
dig google.com +short
Output:
142.250.185.46
Just the IP address, no extra information!
Example 4: Reverse DNS Lookup
dig -x 142.250.185.46
What it does:
Reverse lookup: IP → Domain name
"Who owns this IP address?"
Summary: DNS Resolution Demystified
┌─────────────────────────────────────────────────────────────┐
│ WHAT YOU LEARNED │
└─────────────────────────────────────────────────────────────┘
DNS Purpose:
Translate domain names → IP addresses
DNS Hierarchy:
Root (.) → TLD (.com) → Domain (google.com)
dig Commands:
├── dig . NS → Root servers
├── dig com NS → TLD servers
├── dig google.com NS → Authoritative servers
└── dig google.com → Get IP address
Resolution Flow:
1. Local cache check
2. Recursive resolver
3. Root server → TLD pointer
4. TLD server → Authoritative pointer
5. Authoritative server → IP address
6. Answer returned and cached
Key Concepts:
├── Recursive vs Authoritative servers
├── TTL (caching duration)
└── Different record types (A, NS, MX, etc.)
DNS is critical internet infrastructure:
✓ Every web request depends on it
✓ Distributed for reliability and speed
✓ Cached to reduce load and latency
✓ Hierarchical for scalability
Next time you visit a website, remember:
Behind that instant page load is a sophisticated system querying multiple servers across the globe, all in milliseconds, translating a simple name into the IP address your computer needs.
DNS: The unsung hero of the internet. 🌐
