How DNS Resolution Works: A Deep Dive with dig
The Domain Name System (DNS) is often called the internet's phonebook, but it's far more sophisticated than that simple analogy suggests. Every time you type a URL into your browser, a complex chain of lookups happens behind the scenes to translate human-readable domain names into IP addresses that computers can understand.
In this article, we'll explore DNS resolution from the ground up using the dig command—a powerful diagnostic tool that lets us peek into the DNS resolution process. By the end, you'll understand exactly how your browser finds google.com and why DNS is designed as a hierarchical, distributed system.
What is DNS and Why Does Name Resolution Exist?
Computers communicate using IP addresses like 142.250.185.46, but humans are terrible at remembering long strings of numbers. Domain names like google.com are much more memorable and meaningful.
DNS solves this fundamental problem by acting as a distributed database that maps domain names to IP addresses. But here's the key insight: DNS doesn't store all this information in one place. Instead, it uses a hierarchical system with multiple layers of specialized servers, each responsible for a portion of the namespace.
This design provides several critical benefits:
Scalability: No single server needs to know about every domain on the internet
Reliability: Failures in one part of the system don't bring down the entire DNS infrastructure
Administrative delegation: Organizations can control their own domains without central coordination
Performance: Caching and geographic distribution reduce lookup times
Understanding dig: Your DNS Diagnostic Tool
The dig (Domain Information Groper) command is a flexible tool for querying DNS servers. Unlike the simple nslookup command, dig provides detailed information about the DNS resolution process, making it invaluable for understanding and troubleshooting DNS.
Basic syntax:
dig [options] <domain> [record-type]
When you run dig google.com, you're asking your configured DNS resolver (usually your ISP's or a public resolver like 8.8.8.8) to look up the A record (IPv4 address) for google.com.
But to truly understand DNS, we need to start at the beginning—at the root of the DNS hierarchy.
The DNS Hierarchy: Root → TLD → Authoritative
DNS is structured as an inverted tree. At the top is the root zone (represented by a dot .), which knows about all top-level domains (TLDs) like .com, .org, and .net. Each TLD knows about the authoritative name servers for domains registered under it. Finally, authoritative name servers hold the actual records for specific domains.
This hierarchical structure allows DNS to scale to billions of domains while keeping query resolution efficient.
Step 1: Understanding dig . NS and Root Name Servers
Let's start our journey at the very top of the DNS hierarchy—the root servers.
dig . NS
This command asks: "Who are the authoritative name servers for the root zone?"
Sample output:
; <<>> DiG 9.18.28 <<>> . 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 This Tells Us
The output shows there are 13 root name servers (labeled a through m), operated by different organizations worldwide. These servers are the foundation of the entire DNS system.
Key points:
NS records (Name Server records) indicate which servers are authoritative for a zone
The TTL (518400 seconds ≈ 6 days) indicates how long resolvers can cache this information
These 13 logical servers are actually hundreds of physical servers distributed globally using anycast routing
Every recursive DNS resolver must know how to reach these root servers to start the resolution process
The root servers don't know where google.com is, but they know who to ask: the servers responsible for the .com TLD.
Step 2: Understanding dig com NS and TLD Name Servers
Next, let's find out who manages the .com top-level domain:
dig com NS
Sample output:
; <<>> DiG 9.18.28 <<>> 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 This Tells Us
The .com TLD is managed by 13 name servers operated by Verisign (the registry for .com and .net). These are called gTLD servers (generic Top-Level Domain servers).
Key observations:
The TTL is 172800 seconds (2 days)—still quite long, as TLD infrastructure changes infrequently
These servers know about every domain registered under
.comThey don't store the actual IP addresses for domains, but they know which authoritative name servers to ask
If you were to query one of these gTLD servers directly about google.com, it would respond with a referral to Google's authoritative name servers.
Step 3: Understanding dig google.com NS and Authoritative Name Servers
Now let's find the authoritative name servers for google.com:
dig google.com NS
Sample output:
; <<>> DiG 9.18.28 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11223
;; 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 This Tells Us
Google operates its own authoritative name servers (ns1.google.com through ns4.google.com). These servers hold the actual DNS records for google.com and all its subdomains.
Key insights:
The TTL is 21600 seconds (6 hours)—shorter than root and TLD servers because organizations may need to change their DNS infrastructure
The ADDITIONAL SECTION provides "glue records" (A records for the name servers themselves)—this prevents a chicken-and-egg problem where you'd need to resolve
ns1.google.comto find Google's name serversThese are the servers of record—they have the authoritative information about Google's domain
Step 4: Understanding dig google.com and Full DNS Resolution
Finally, let's get the actual IP address:
dig google.com
Sample output:
; <<>> DiG 9.18.28 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33445
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jan 30 10:15:30 PST 2026
;; MSG SIZE rcvd: 55
What This Tells Us
We finally have the IP address: 142.250.185.46. But notice the TTL is only 300 seconds (5 minutes)—much shorter than the NS records we saw earlier.
Why the short TTL?
Google can quickly change where
google.compoints (for load balancing, failover, or maintenance)Users will get updated IP addresses within 5 minutes
This is a common pattern: infrastructure records (NS) have longer TTLs, while application records (A, AAAA) have shorter TTLs
The Complete DNS Resolution Flow
Now let's put it all together. Here's what happens when you type google.com into your browser:
Breaking Down the Resolution Process
Browser check: Your browser first checks its own cache
Operating system check: If not cached, the OS checks its DNS cache
Recursive resolver query: Your configured DNS resolver (ISP or public DNS like 8.8.8.8) is queried
Resolver cache check: The resolver checks its cache
Root query: If not cached, the resolver asks a root server "Who handles
.com?"TLD query: The resolver asks the
.comTLD server "Who handlesgoogle.com?"Authoritative query: The resolver asks Google's authoritative server "What's the IP for
google.com?"Response and caching: The resolver caches the result and returns it to your browser
This entire process typically completes in under 100 milliseconds, even when nothing is cached.
Recursive Resolvers: The Unsung Heroes
The recursive resolver does the heavy lifting in DNS resolution. When you configure your network to use 8.8.8.8 (Google Public DNS) or 1.1.1.1 (Cloudflare DNS), you're specifying which recursive resolver to use.
What recursive resolvers do:
Perform the entire chain of queries on your behalf
Maintain massive caches to avoid repeating queries
Handle retries and failover if servers don't respond
Implement security features like DNSSEC validation
May filter malicious domains or provide content filtering
Why they matter:
Without recursive resolvers, every device would need to implement the complex DNS resolution algorithm
Caching at the resolver level benefits all users sharing that resolver
They provide a natural place to implement DNS-based security and privacy features
What NS Records Represent and Why They Matter
Throughout this article, we've queried NS (Name Server) records. These records are fundamental to how DNS delegation works.
NS records indicate:
Which servers are authoritative for a given zone
Where to continue the resolution process when descending the hierarchy
Organizational boundaries in the DNS namespace
Why they're critical:
They enable delegation—the root servers don't need to know about
google.com, they just need to know who to askThey provide redundancy—multiple NS records mean multiple servers can answer queries
They allow organizations to control their own DNS infrastructure
When you register a domain, you're essentially adding NS records to the parent zone (the TLD) that point to your chosen authoritative servers.
Practical Insights for System Design
Understanding DNS resolution has practical implications for system architecture:
1. DNS is a natural caching layer
Design your systems to leverage DNS TTLs appropriately:
Use shorter TTLs (5-15 minutes) for records you may need to change frequently
Use longer TTLs (hours to days) for stable infrastructure
Consider that DNS changes aren't instant—plan maintenance windows accordingly
2. DNS provides built-in load distribution
Multiple A records for the same domain enable simple round-robin load balancing:
dig google.com
;; ANSWER SECTION:
google.com. 300 IN A 142.250.185.46
google.com. 300 IN A 142.250.185.78
google.com. 300 IN A 142.250.185.110
Resolvers will typically rotate through these addresses, distributing load.
3. DNS enables geographic routing
Services like AWS Route 53 and Cloudflare can return different IP addresses based on the client's location, routing users to the nearest data center.
4. DNS is a single point of failure
If your authoritative name servers are unreachable, your entire service is effectively offline, even if your application servers are healthy. Always:
Use multiple authoritative name servers in different networks
Consider using a managed DNS service with global presence
Monitor your DNS infrastructure
5. DNS can be slow
Even though resolution is usually fast, the chain of queries adds latency. Modern applications often:
Implement aggressive client-side DNS caching
Use connection pooling to amortize DNS lookup costs
Pre-resolve critical domains during application startup
Real-World Browser Behavior
When you type google.com into your browser and press Enter, here's what actually happens:
Key observations:
Multiple layers of caching mean most requests never leave your local machine
DNS is just one step in a complex process—TLS handshakes and HTTP requests add additional latency
Modern browsers often pre-resolve DNS for links on a page to speed up navigation
HTTP/2 and HTTP/3 allow multiplexing multiple requests over a single connection, reducing the impact of DNS lookups
Debugging DNS with dig
The dig command offers several useful options for troubleshooting:
Trace the full resolution path
dig +trace google.com
This shows each step: root → TLD → authoritative, performing the queries manually instead of relying on your recursive resolver.
Query a specific server
dig @8.8.8.8 google.com
Explicitly use Google's DNS resolver instead of your default.
Request specific record types
dig google.com MX # Mail servers
dig google.com TXT # Text records (SPF, DKIM, verification)
dig google.com AAAA # IPv6 addresses
Short output
dig +short google.com
Returns just the IP address, useful for scripting.
Conclusion
DNS is a marvel of distributed systems engineering. Its hierarchical design allows it to scale to billions of domains while remaining fast and resilient. By understanding the resolution flow—from root servers to TLD servers to authoritative servers—you gain insight into one of the internet's most critical pieces of infrastructure.
The dig command transforms DNS from a black box into something you can explore and understand. Whether you're debugging connectivity issues, designing a new service, or just curious about how the internet works, knowing how to trace a DNS query from your browser to the authoritative source is an invaluable skill.
Next time you type a URL into your browser, you'll know exactly what's happening behind that simple action: a carefully orchestrated dance between recursive resolvers, root servers, TLD servers, and authoritative name servers, all working together to connect you to the service you're looking for.
Try It Yourself
Run these commands to explore DNS resolution for different domains:
# Compare DNS infrastructure for different organizations
dig netflix.com NS
dig amazon.com NS
dig cloudflare.com NS
# See how many IP addresses popular sites use
dig facebook.com
dig twitter.com
# Explore DNS records for a domain you own
dig your-domain.com ANY
Each organization makes different trade-offs in their DNS architecture. By examining these choices, you'll develop intuition for how to design robust, scalable DNS infrastructure for your own projects.
