Understanding DNS Resolution with the dig Command
The Internet's Directory System
Every time you type "google.com" into your browser, something remarkable happens behind the scenes. Your computer doesn't actually know where Google's servers are. It needs to ask for directions. This is where the Domain Name System (DNS) comes in.
Think of DNS as the internet's phone book, but instead of looking up phone numbers, it looks up IP addresses. When you want to visit "google.com," DNS translates that human-friendly name into a computer-friendly IP address like 142.250.185.46. Your browser then uses that IP address to connect to Google's servers.
But here's the interesting part: this translation doesn't happen in one place. It's not like there's a single massive database somewhere that knows every domain name on the internet. Instead, DNS works like a distributed filing system with multiple layers, each responsible for a different piece of the puzzle.
To really understand how this works, we need a tool that lets us peek behind the curtain. That tool is dig.
What is dig and Why Do We Need It?
dig stands for "Domain Information Groper" (yes, really). It's a command-line tool that lets you query DNS servers and see exactly what's happening during name resolution.
While your browser handles DNS lookups automatically and invisibly, dig shows you the whole conversation. It's like turning on subtitles for the internet's internal dialogue.
When do you use dig?
Debugging: Your website isn't loading?
digshows you if DNS is working correctly.Verification: You just updated DNS records and want to confirm they've propagated.
Learning: Understanding how DNS actually works at a practical level.
System Design: Designing distributed systems that rely on DNS for service discovery.
Basic syntax:
dig [domain] [record-type]
For example:
dig google.com # Get A records (IP addresses)
dig google.com NS # Get name server records
dig google.com MX # Get mail server records
Now, let's use dig to understand how DNS resolution actually works, layer by layer.
The DNS Hierarchy: A Three-Layer System
Before we run any commands, you need to understand that DNS is organized hierarchically, like a tree structure:
Root (.)
|
+----------------------------+
| | |
.com .org .net ← TLD (Top-Level Domain)
|
google.com ← Authoritative Domain
The three layers:
Root Name Servers (.) - Know about all top-level domains (.com, .org, .net, etc.)
TLD Name Servers - Know about all domains within their TLD (e.g., all .com domains)
Authoritative Name Servers - Know the actual IP addresses for specific domains
When you look up "google.com," your computer doesn't know where it is. It has to ask this chain of servers, starting from the top and working its way down. Let's see this in action.
Understanding dig . NS - The Root Name Servers
The root of the entire DNS system is represented by a single dot (.). The root name servers are the foundation of internet infrastructure. There are 13 root server networks (labeled A through M) distributed worldwide.
Let's query the root servers:
dig . NS
What you'll see:
; <<>> DiG 9.18.24 <<>> . NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; 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 does this mean?
NS stands for "Name Server" - these records tell you who's responsible for answering questions about a domain
The root (
.) has 13 name servers:a.root-servers.netthroughm.root-servers.netThe number
518400is the TTL (Time To Live) in seconds—about 6 daysThese root servers don't know about specific websites, but they know which servers handle each top-level domain
Why this matters:
Root servers are the starting point for all DNS resolution. They're essentially saying: "I don't know where google.com is, but I know who handles all .com domains. Go ask them."
These 13 root server networks are operated by different organizations and are replicated using anycast routing across hundreds of physical servers worldwide. This redundancy ensures the internet keeps working even if some servers go down.
Understanding dig com NS - TLD Name Servers
Now let's go one level deeper. The .com top-level domain is one of the most popular TLDs on the internet. Let's ask: who's responsible for .com domains?
dig com NS
What you'll see:
; <<>> DiG 9.18.24 <<>> com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54321
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; 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 does this mean?
The
.comTLD is managed by 13 name servers (a through m.gtld-servers.net)"GTLD" stands for "Generic Top-Level Domain"
TTL is 172800 seconds (2 days)
These servers are operated by Verisign, the company contracted to manage the .com registry
Why this matters:
TLD name servers sit in the middle of the DNS hierarchy. They know about all domains registered under their TLD, but they don't store the actual IP addresses. Instead, they know which authoritative name servers to ask for each specific domain.
If you ask a .com TLD server about "google.com," it won't give you Google's IP address. Instead, it'll say: "Google's authoritative name servers are ns1.google.com, ns2.google.com, etc. Go ask them."
The delegation pattern:
Notice the pattern here:
Root servers delegate to TLD servers
TLD servers delegate to authoritative servers
This delegation is what makes DNS scalable. No single server needs to know everything—they just need to know who to ask next.
Understanding dig google.com NS - Authoritative Name Servers
Now we're getting specific. Let's find out which name servers are authoritative for google.com—meaning they have the final say on all DNS records for that domain.
dig google.com NS
What you'll see:
; <<>> DiG 9.18.24 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24680
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9
;; 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.
;; 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
What does this mean?
Google.com is managed by 4 authoritative name servers
These servers are named ns1 through ns4.google.com
The ADDITIONAL SECTION helpfully provides the IP addresses of these name servers (called "glue records")
TTL is 21600 seconds (6 hours)
Why the ADDITIONAL SECTION matters:
Here's an interesting chicken-and-egg problem: if you need to look up google.com and you're told to ask ns1.google.com, but you don't know where ns1.google.com is... how do you find it?
That's why the parent zone (.com servers) also returns "glue records"—the IP addresses of the name servers themselves. This breaks the circular dependency.
Why multiple name servers?
Google runs 4 authoritative name servers for redundancy and load distribution:
If one goes down, the other three can still answer queries
Traffic can be distributed across all four
They can be geographically distributed for better performance
When you register a domain, you specify which name servers are authoritative for it. Those NS records are then stored in the parent zone (.com in this case).
Understanding dig google.com - The Full Resolution Flow
Now for the finale. When you actually want to visit google.com, your computer needs the IP address. Let's see what happens when we query for it directly (which queries for A records by default).
dig google.com
What you'll see:
; <<>> DiG 9.18.24 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13579
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 31 10:30:45 UTC 2026
;; MSG SIZE rcvd: 55
Breaking down the output:
QUESTION SECTION:
- We asked: "What is the A record for google.com?"
ANSWER SECTION:
google.com points to IP address
142.250.185.46TTL is 300 seconds (5 minutes) - much shorter than NS records
This is the actual IP address your browser will connect to
Metadata:
Query took 24 milliseconds
We queried server 8.8.8.8 (Google's public DNS resolver) on port 53
Total response size was 55 bytes
Why is the TTL shorter?
Notice that the A record has a TTL of just 300 seconds (5 minutes), while NS records have TTLs of hours or days. This is intentional:
NS records change rarely - companies don't often switch DNS providers, so longer TTLs are safe
A records may change more often - companies might need to redirect traffic quickly (for maintenance, load balancing, or failover)
A shorter TTL means changes propagate faster, but it also means more DNS queries are needed since the cache expires sooner.
Behind the Scenes: What Your Recursive Resolver Actually Does
When you run dig google.com, here's what happens behind the scenes. Your computer (or the DNS resolver you're using) performs what's called "recursive resolution":
Step-by-step flow:
1. Your computer: "What's the IP for google.com?"
└─> Asks recursive resolver (e.g., 8.8.8.8)
2. Recursive resolver: "I don't know yet, let me find out."
└─> Asks root server: "Who handles .com?"
3. Root server: "Ask the .com TLD servers"
└─> Returns: a.gtld-servers.net, b.gtld-servers.net, etc.
4. Recursive resolver: "Who handles google.com?"
└─> Asks .com TLD server
5. TLD server: "Ask Google's authoritative servers"
└─> Returns: ns1.google.com, ns2.google.com, etc.
6. Recursive resolver: "What's the IP for google.com?"
└─> Asks ns1.google.com (Google's authoritative server)
7. Authoritative server: "Here it is!"
└─> Returns: 142.250.185.46
8. Recursive resolver: "Got it! Here's your answer."
└─> Returns to your computer and caches the result
Important note: When you run dig, you typically don't see all these intermediate steps because your recursive resolver (like 8.8.8.8) does all the work for you and has likely cached the intermediate results.
If you want to see each step manually, you can use the +trace option:
dig +trace google.com
This shows you the complete chain from root → TLD → authoritative, exactly as we walked through manually.
Connecting to Real-World Browser Requests
Let's connect this back to what actually happens when you type "google.com" in your browser:
The browser's journey:
Check local cache: Has the browser already looked up google.com recently? If yes, use the cached IP.
Check OS cache: The operating system maintains its own DNS cache. Check there.
Query recursive resolver: Ask your configured DNS server (often provided by your ISP or a public DNS like 8.8.8.8).
Recursive resolver does the work: If it doesn't have the answer cached, it performs the root → TLD → authoritative lookup we just explored.
Return the IP: The resolver returns
142.250.185.46to your browser.Establish connection: Your browser opens a TCP connection to
142.250.185.46on port 443 (for HTTPS).Send HTTP request: Browser sends "GET / HTTP/1.1" to Google's server.
Receive response: Google's server sends back the HTML for their homepage.
All of this typically happens in under 100 milliseconds. DNS resolution might only take 20-50ms of that, especially if results are cached.
Why NS Records Matter in System Design
Understanding NS records isn't just academic—it's crucial for designing reliable distributed systems:
Service Discovery: Modern microservices often use DNS for service discovery. Internal services might have records like:
api.internal.company.com → ns1.internal.company.com
Geographic Distribution: Companies use DNS to route users to the nearest data center:
dig google.com
# Might return different IPs based on where you are in the world
Load Balancing: Authoritative name servers can return different A records to distribute load:
# One query might get: 142.250.185.46
# Another might get: 142.250.185.78
Failover: If a server goes down, DNS can be updated to point to a backup:
# Before: example.com → 198.51.100.1 (primary)
# After: example.com → 198.51.100.2 (backup)
Multi-Cloud Strategy: Companies running on multiple cloud providers use DNS to route traffic:
# AWS servers: use-1.example.com → AWS IP
# GCP servers: gcp-1.example.com → GCP IP
# Main domain: example.com → CNAME to best option
Common Patterns and Best Practices
Multiple NS records for reliability: Always use at least 2 authoritative name servers, preferably 4. They should be:
On different networks
In different geographic locations
Managed by different providers (if possible)
Shorter TTLs for critical records: If you might need to change an A record quickly (for maintenance or failover), use a shorter TTL like 300-600 seconds.
Longer TTLs for stable records: NS records, MX records, and other infrastructure records can have TTLs of hours or days since they change rarely.
Use +short for scripts: If you're writing scripts that need to parse DNS output, use dig +short:
dig google.com +short
# Output: 142.250.185.46
Trace the full path when debugging: When troubleshooting DNS issues, use +trace to see every step:
dig +trace example.com
This shows you exactly where in the chain things might be failing.
Visualizing the Complete Flow
Let's put it all together with a visual representation of what we've learned:
┌─────────────────┐
│ Your Browser │ "I need google.com"
│ dig google.com│
└────────┬────────┘
│
▼
┌─────────────────────┐
│ Recursive Resolver │ (e.g., 8.8.8.8)
│ "Let me find out" │
└──────────┬──────────┘
│
├─────────────────────────────────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Root Servers │ dig . NS │ (Cached?) │
│ a-m.root- │ "Ask .com servers" │ Skip to step │
│ servers.net │ │ 3 or 4 │
└──────┬───────┘ └──────────────┘
│
▼
┌──────────────┐
│ TLD Servers │ dig com NS
│ a-m.gtld- │ "Ask Google's
│ servers.net │ name servers"
└──────┬───────┘
│
▼
┌──────────────┐
│ Authoritative│ dig google.com NS
│ ns1-4.google │ "Here are Google's
│ .com │ name servers"
└──────┬───────┘
│
▼
┌──────────────┐
│ Authoritative│ dig google.com
│ ns1.google │ "google.com is at
│ .com │ 142.250.185.46"
└──────┬───────┘
│
▼
┌──────────────┐
│ Browser │ Connects to
│ Connects │ 142.250.185.46:443
└──────────────┘
Key Takeaways
DNS is hierarchical: Root → TLD → Authoritative servers form a delegation chain.
NS records are signposts: They don't contain the final answer; they tell you who to ask next.
Recursive resolvers do the heavy lifting: Your browser doesn't walk the entire chain—recursive resolvers do it on your behalf.
Caching is everywhere: Every layer caches results to avoid redundant queries. This is why DNS is fast despite multiple lookups.
The
digcommand reveals the process: Each command we ran (dig . NS,dig com NS,diggoogle.comNS,diggoogle.com) corresponds to a step in the resolution process.TTLs control cache duration: Shorter TTLs mean fresher data but more queries. Longer TTLs mean less load but slower updates.
Redundancy is built-in: Multiple root servers, multiple TLD servers, multiple authoritative servers—failure at any level doesn't break the internet.
Final Thoughts
DNS is one of those technologies that "just works" so well that most people never think about it. But understanding how it works—really works, at the protocol level—makes you a better systems engineer.
When you design distributed systems, you'll make better decisions about:
How to structure your internal DNS
What TTLs to use for different record types
How to implement geographic routing
How to handle failover scenarios
How to debug mysterious "it works for me but not for them" issues
The next time you type a domain name, you'll know exactly what's happening: your computer starting at the root of the internet's directory tree and following the chain of delegation until it finds the answer. And with dig, you can watch that entire process unfold, one query at a time.
DNS is the internet's phone book, but it's so much more elegant than that. It's a distributed, fault-tolerant, globally replicated database that handles billions of queries per second—and it all starts with those 13 root servers we found with dig . NS.
