Every URL you type triggers a global treasure hunt. Let's trace it.
You type google.com in your browser. Within milliseconds, Google's homepage appears.
But your computer doesn't know what "google.com" means. It only understands IP addresses like 142.250.193.46. Something had to translate that name into a number.
That something is DNS.
This article will show you exactly how DNS resolution works by using the dig command to trace each step of the journey—from root servers to the final IP address.
What you'll learn:
- What DNS is and why it exists
- How to use
digto inspect DNS resolution - The three-layer DNS hierarchy: Root → TLD → Authoritative
- What actually happens when your browser resolves a domain
Part 1: DNS — The Internet's Phonebook
The Problem
Humans remember names: google.com, github.com, amazon.com
Computers need numbers: 142.250.193.46, 140.82.112.4, 54.239.28.85
DNS (Domain Name System) is the translation layer between human-readable names and machine-readable IP addresses.
Why Not Just Use IP Addresses?
| If We Used... | Problem |
|---|---|
| IP addresses directly | Impossible to remember |
| A single giant lookup table | Can't scale to billions of domains |
| Local files on each computer | Impossible to keep updated |
DNS solves this with a distributed, hierarchical system. No single server knows everything, but together they can resolve any domain.
Part 2: The DNS Hierarchy
DNS is organized like an inverted 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)
└──────────┘ └──────────┘ └──────────┘
The Three Layers
| Layer | What It Knows | Who Controls It |
|---|---|---|
| Root Servers | "Where to find .com, .org, .net, etc." | ICANN / Internet governance |
| TLD Servers | "Where to find google.com, amazon.com, etc." | Registry operators (Verisign for .com) |
| Authoritative Servers | "google.com = 142.250.193.46" | The domain owner (Google) |
Key Insight: Each layer only knows where to find the NEXT layer. Root doesn't know Google's IP—it only knows who handles .com.
Part 3: The dig Command — Your DNS Detective Tool
What is dig?
dig (Domain Information Groper) is a command-line tool for querying DNS servers. It lets you see exactly what happens during DNS resolution.
Why Software Engineers Should Know dig
| Scenario | dig Helps You |
|---|---|
| "Website not loading" | Check if DNS is resolving |
| "Deployed but domain not working" | Verify DNS propagation |
| "SSL certificate issues" | Confirm DNS points to right server |
| "Setting up email" | Check MX records |
Basic Syntax
dig [domain] [record-type]
# Examples:
dig google.com # Get A record (IP address)
dig google.com NS # Get name servers
dig google.com MX # Get mail servers
dig google.com +short # Compact output
Reading dig Output
$ dig google.com
; <<>> DiG 9.18.1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;google.com. IN A ← What we asked
;; ANSWER SECTION:
google.com. 300 IN A 142.250.193.46 ← The answer!
↑ ↑
TTL IP Address
(seconds)
;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
| Section | What It Shows |
|---|---|
| QUESTION | What you asked for |
| ANSWER | The response (IP address, name server, etc.) |
| TTL | How long to cache this answer (in seconds) |
| SERVER | Which DNS server answered |
Part 4: dig . NS — Discovering Root Servers
Let's start at the very top of the DNS hierarchy.
The Command
$ dig . 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.
What This Means
- The
.represents the ROOT of the DNS tree
NSmeans "Name Server" records- There are 13 root server clusters named
athroughm
- TTL of 518400 = 6 days (root server info rarely changes)
Why Only 13?
Technical limitation: DNS responses must fit in 512 bytes (traditional UDP). 13 server names + their IPs barely fit.
But each letter is actually a cluster of hundreds of servers worldwide using Anycast. When you query a.root-servers.net, you're routed to the nearest physical server.
What Root Servers Know
Root servers DON'T know every domain. They only know:
- Where to find
.comservers - Where to find
.orgservers - Where to find
.net,.io,.dev, country codes, etc.
They point you to the next layer: TLD servers.
Part 5: dig com NS — Discovering TLD Servers
Now let's find who handles all .com domains.
The Command
$ dig 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.
What This Means
gtld-servers.net= Generic Top-Level Domain servers- These are run by Verisign (they manage the .com registry)
- TTL of 172800 = 2 days
What TLD Servers Know
TLD servers DON'T know Google's IP address. They only know:
google.comis managed by name servers atns1.google.com,ns2.google.com, etc.
amazon.comis managed by name servers atns1.amazon.com, etc.
They point you to the next layer: Authoritative servers.
Different TLDs, Different Operators
| TLD | Operator |
|---|---|
.com, .net | Verisign |
.org | Public Interest Registry |
.io | Internet Computer Bureau |
.dev, .app | Google Registry |
.in, .uk, .de | Country registries |
Part 6: dig google.com NS — Discovering Authoritative Servers
Now let's find exactly who is responsible for google.com.
The Command
$ dig 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.
What This Means
- These are Google's own DNS servers
- They are authoritative for
google.com—they have the final answer - TTL of 21600 = 6 hours
- Google runs 4 name servers for redundancy
What "Authoritative" Means
| Server Type | Knows The Answer? | Can Be Wrong? |
|---|---|---|
| Root servers | No (only knows TLD) | N/A |
| TLD servers | No (only knows NS) | N/A |
| Authoritative servers | YES | No—this is the source of truth |
The authoritative server IS the domain owner's server. When Google updates their IP, they update these servers. The change propagates from here.
Why NS Records Matter
When you buy a domain (e.g., from GoDaddy, Namecheap), you set NS records to point to your DNS provider:
- Point to Cloudflare:
ns1.cloudflare.com
- Point to AWS Route53:
ns-123.awsdns-45.com
- Point to your own:
ns1.yourdomain.com
Whoever controls the NS records controls the domain.
Part 7: dig google.com — The Full Resolution
Finally, let's get the actual IP address.
The Command
$ dig google.com
;; ANSWER SECTION:
google.com. 300 IN A 142.250.193.46
What This Means
| Field | Value | Meaning |
|---|---|---|
google.com. | Domain | What we queried |
300 | TTL | Cache for 5 minutes |
IN | Class | Internet (always this) |
A | Record Type | IPv4 address |
142.250.193.46 | Answer | Google's IP! |
Getting IPv6 (AAAA Record)
$ dig google.com AAAA
;; ANSWER SECTION:
google.com. 300 IN AAAA 2607:f8b0:4004:800::200e
The +short Flag
For scripting or quick checks:
$ dig google.com +short
142.250.193.46
Why TTL is 300 (5 minutes)
Google's TTL is short because:
- They have multiple data centers worldwide
- They use DNS for load balancing (different users get different IPs)
- They can quickly switch traffic during outages
Longer TTL = Less DNS queries, but slower updates
Shorter TTL = More DNS queries, but faster failover
Part 8: The Complete Resolution Flow
Now let's trace the complete journey when your browser resolves google.com.
Diagram: Step-by-Step Resolution
┌─────────────────────────────────────────────────────────────────────────────┐
│ 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!
Recursive vs Iterative Resolution
| Type | Who Does The Work | Used By |
|---|---|---|
| Recursive | Resolver does all the work, returns final answer | Your ISP's DNS, Google (8.8.8.8), Cloudflare (1.1.1.1) |
| Iterative | Each server just gives a referral to the next | How resolvers talk to authoritative servers |
Your browser makes ONE request. The recursive resolver does the rest.
The dig +trace Command
You can see the entire journey with:
$ dig google.com +trace
; <<>> DiG 9.18.1 <<>> google.com +trace
. 86400 IN NS a.root-servers.net.
;; Received 811 bytes
com. 172800 IN NS a.gtld-servers.net.
;; Received 1170 bytes
google.com. 172800 IN NS ns1.google.com.
;; Received 660 bytes
google.com. 300 IN A 142.250.193.46
;; Received 55 bytes
This shows every step: Root → TLD → Authoritative → Answer.
Caching — Why It's Usually Faster
Most of the time, you don't see all 4 queries because of caching:
| Cache Location | What It Caches | TTL |
|---|---|---|
| Your browser | Final IP address | Minutes |
| Your OS | Final IP address | Minutes to hours |
| Recursive resolver | Root, TLD, auth, and IPs | Based on each record's TTL |
First query: 50-100ms (full resolution)
Cached query: 1-5ms (from local cache)
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
Part 9: Real-World Implications
Why DNS Matters for System Design
| Concept | How DNS Is Used |
|---|---|
| Load Balancing | Return different IPs to distribute traffic |
| Geo-routing | Return nearest data center's IP based on user location |
| Failover | If primary server dies, update DNS to point to backup |
| Blue-Green Deployment | Switch traffic by updating DNS records |
| CDN | CDN providers use DNS to route to edge servers |
DNS Propagation Delays
When you change a DNS record, it doesn't update instantly:
You change: google.com → 1.2.3.4
But caches worldwide still have the old IP for TTL duration
Timeline:
0 min: You update the record
1 min: Some users see new IP
5 min: More users see new IP (TTL=300)
1 hour: Most users see new IP
24 hours: Almost everyone sees new IP (some caches ignore TTL)
Pro tip: Before a big migration, lower TTL to 60 seconds days in advance.
Common DNS Debugging Scenarios
| Problem | dig Command | What to Check |
|---|---|---|
| Domain not resolving | dig domain.com | Is there an A record? |
| Wrong IP after change | dig domain.com +trace | Is propagation complete? |
| Email not working | dig domain.com MX | Are MX records correct? |
| SSL cert issues | dig domain.com CNAME | Is CNAME pointing correctly? |
| Using wrong DNS | dig @8.8.8.8 domain.com | Compare with different resolver |
Part 10: Quick Reference
dig Commands Cheat Sheet
| Command | What It Does |
|---|---|
dig google.com | Get A record (IPv4) |
dig google.com AAAA | Get IPv6 address |
dig google.com NS | Get name servers |
dig google.com MX | Get mail servers |
dig google.com TXT | Get TXT records (SPF, verification) |
dig google.com +short | Compact output |
dig google.com +trace | Show full resolution path |
dig @8.8.8.8 google.com | Query specific DNS server |
dig . NS | Get root servers |
dig com NS | Get TLD servers |
DNS Record Types Summary
| Type | Purpose | Example |
|---|---|---|
| A | IPv4 address | google.com → 142.250.193.46 |
| AAAA | IPv6 address | google.com → 2607:f8b0:... |
| NS | Name server | google.com → ns1.google.com |
| MX | Mail server | google.com → smtp.google.com |
| CNAME | Alias | www.google.com → google.com |
| TXT | Text data | SPF records, domain verification |
| SOA | Start of Authority | Primary NS, admin email, serial |
The Mental Model
When you type google.com:
1. Browser asks recursive resolver: "What's google.com?"
2. Resolver asks ROOT: "Who handles .com?" → "gtld-servers.net"
3. Resolver asks TLD: "Who handles google.com?" → "ns1.google.com"
4. Resolver asks AUTHORITATIVE: "What's google.com's IP?" → "142.250.193.46"
5. Resolver returns IP to browser
6. Browser connects to 142.250.193.46
7. Google's server responds
8. Page loads!
Conclusion
DNS is a distributed, hierarchical lookup system.
| Key Takeaway | Remember |
|---|---|
| Three layers | Root → TLD → Authoritative |
| Each layer only knows the next | No single server knows everything |
| dig traces the journey | Use it to debug DNS issues |
| Caching speeds things up | But delays propagation |
| TTL controls cache lifetime | Lower before migrations |
Next time you see a "DNS not found" error, you now know exactly where to look and what commands to run.
Now you can trace any domain's journey across the internet. Happy debugging! 🔍
SOCIAL SHARE CARD GENERATOR