Imagine trying to find a friend's house without a street address. You'd need to ask around, get directed to neighborhoods, then to specific areas, and finally to their street. That's essentially what happens every time you visit a website—your browser needs to convert a human-readable domain name like google.com into an IP address that computers can understand. This translation process is DNS (Domain Name System), the internet's phonebook.

In this article, we'll explore DNS resolution by using the dig command—a powerful diagnostic tool that reveals the behind-the-scenes magic of how names get resolved to IP addresses.

What is DNS?

DNS stands for Domain Name System. It's a hierarchical system that translates domain names into IP addresses. Without DNS, you'd have to remember and type IP addresses like 142.251.32.46 to visit Google instead of typing google.com.

Why Name Resolution Exists

There are three main reasons why name resolution is critical:

1. Human-Friendly: IP addresses are hard to remember; domain names are intuitive

2. Scalability: As servers move or IP addresses change, only DNS records need updating—users still use the same domain

3. Load Distribution: Multiple IP addresses can be assigned to one domain for load balancing

What is the dig Command?

dig (Domain Information Groper) is a command-line tool for querying DNS servers. It's invaluable for:

• Debugging DNS issues

• Understanding how DNS resolution works

• Verifying DNS records are correctly configured

• Troubleshooting connectivity issues

• Learning system design and network architecture

When to Use dig

• Your website isn't loading but the server is online

• You're setting up DNS records and want to verify they're live

• You need to understand the DNS resolution path

• You're preparing for system design interviews

DNS Resolution: The Hierarchical Layers

DNS resolution works in three main layers, each with specific name servers:

1. Root Name Servers - Know where TLD servers are located

2. TLD (Top-Level Domain) Servers - Know where authoritative servers for specific domains are

3. Authoritative Name Servers - Hold the actual DNS records for a domain

Let's explore each layer using dig commands.

Layer 1: Understanding Root Name Servers with dig . NS

Root name servers are the first stop in DNS resolution. They don't hold actual records; instead, they redirect queries to the appropriate TLD servers.

Running the Command

dig . NS

This command asks: "Who are the root name servers?"

Understanding the Output

You'll see results like:

; <<>> DiG 9.10.6 <<>> . NS
; (1 server found)
;; 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:
.    518400    IN    NS    a.root-servers.net.
.    518400    IN    NS    b.root-servers.net.
.    518400    IN    NS    c.root-servers.net.
; ... (more root servers)

What This Means

• There are 13 root name servers (labeled a through m)

• These are distributed globally for redundancy

• They cache the locations of all TLD servers

• The TTL (Time To Live) is 518400 seconds (6 days)

• These root servers are the Internet's foundational infrastructure

Layer 2: Understanding TLD Servers with dig com NS

Once your recursive resolver knows where the root servers are, it asks them: "Where do I find information about .com domains?"

Running the Command

dig com NS

This queries the root servers to find which servers manage .com domains.

Understanding the Output

; <<>> 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.
; ... (more TLD servers)

What This Means

• There are 13 TLD servers for .com domains (generic TLDs have multiple servers)

• These are called gTLD servers (Global Top-Level Domain)

• The TTL is 172800 seconds (2 days)

• These servers know which companies own which .com domains

• For every TLD (.org, .edu, .net, .in, etc.), there are dedicated TLD servers

Layer 3: Understanding Authoritative Servers with dig google.com NS

Now we're getting specific. After the recursive resolver contacts a TLD server, it asks: "Where do I find DNS information specifically for google.com?"

Running the Command

dig google.com NS

This queries TLD servers to find the authoritative name servers for google.com.

Understanding the Output

;; ANSWER SECTION:
google.com.    172800    IN    NS    ns1.google.com.
google.com.    172800    IN    NS    ns2.google.com.
google.com.    172800    IN    NS    ns3.google.com.
google.com.    172800    IN    NS    ns4.google.com.

What This Means

• Google runs its own authoritative name servers for google.com

• These servers (ns1.google.com, ns2.google.com, etc.) hold the actual DNS records

• The TTL is 172800 seconds (2 days)

• Only authoritative servers can respond authoritatively to queries about google.com

• Other companies can't claim authority over google.com records

Layer 4: Complete DNS Resolution with dig google.com

Now let's see the complete journey. This command performs the full DNS resolution—it's what happens when you type a URL in your browser.

Running the Command

dig google.com

This performs a complete recursive resolution query.

Understanding the Output

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;google.com.            IN    A

;; ANSWER SECTION:
google.com.        300    IN    A    142.251.32.46

;; AUTHORITY SECTION:
google.com.        172800    IN    NS    ns1.google.com.
google.com.        172800    IN    NS    ns2.google.com.
google.com.        172800    IN    NS    ns3.google.com.
google.com.        172800    IN    NS    ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.        172800    IN    A    216.239.32.10
ns2.google.com.        172800    IN    A    216.239.34.10
ns3.google.com.        172800    IN    A    216.239.36.10
ns4.google.com.        172800    IN    A    216.239.38.10

Breaking Down the Output

QUESTION SECTION: What are we looking for?

• We're looking for an A record (IPv4 address) for google.com

ANSWER SECTION: The actual result

• google.com resolves to 142.251.32.46

• TTL is 300 seconds (5 minutes)—this answer will be cached

AUTHORITY SECTION: Who said this?

• The authoritative name servers that answered this query

• Shows Google's four name servers

ADDITIONAL SECTION: Bonus information

• The IP addresses of the authoritative name servers themselves

• Helps avoid additional DNS lookups

Understanding NS Records

NS (Name Server) records are the backbone of DNS:

• They tell you "which server is responsible for this domain?"

• At each layer (root, TLD, authoritative), NS records delegate to the next level

• Root NS records point to TLD servers

• TLD NS records point to authoritative servers

• Authoritative servers provide the actual A/AAAA/CNAME records

The Complete DNS Resolution Flow

Here's what happens when you visit google.com:

1. Browser Query: Your browser asks your recursive resolver for google.com's IP

2. Recursive Resolver Contacts Root: The resolver queries a root name server

3. Root Server Responds: "I don't know google.com, but ask the .com TLD servers"

4. Query TLD Server: The resolver asks a .com TLD server

5. TLD Server Responds: "I don't have the record, but ask google's authoritative servers"

6. Query Authoritative Server: The resolver asks ns1.google.com

7. Authoritative Server Responds: "google.com is 142.251.32.46"

8. Caching: The resolver caches this result (for the TTL period)

9. Browser Connects: Your browser connects to 142.251.32.46

Recursive Resolvers: The Invisible Workers

Behind the scenes, recursive resolvers (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) do the heavy lifting:

• They follow the DNS hierarchy layer by layer

• They cache results to avoid repeated queries

• They return results to clients even if they have to query multiple servers

• They're typically provided by your ISP or run on your local machine

Real-World Connection: From dig to Browser

When you type google.com in your browser:

1. Browser queries your system's resolver

2. System resolver performs the same steps as dig google.com

3. All three layers are contacted (root → TLD → authoritative)

4. The final IP address is returned and cached

5. Browser uses that IP to establish an HTTPS connection

6. Server responds and your browser displays the page

Practical Dig Commands for System Design

Here are other useful dig queries for understanding DNS:

# Get MX records (mail servers)
dig google.com MX

# Get all records
dig google.com ANY

# Query a specific name server
dig @ns1.google.com google.com

# Show DNSSEC information
dig google.com +dnssec

# Show query process step by step
dig google.com +trace

Key Takeaways

1. DNS is hierarchical: Root → TLD → Authoritative

2. Each layer serves a purpose: Delegation, optimization, and finally returning the IP

3. dig reveals the process: You can see exactly how name resolution works

4. NS records are the delegation mechanism: They point to the next server in the chain

5. Caching is crucial: TTL values balance between accuracy and performance

6. System design matters: Understanding DNS is essential for building scalable systems

Conclusion

The dig command transforms DNS from a mysterious black box into an understandable system. By querying each layer separately (root, TLD, authoritative) and then performing a complete resolution, you've learned how billions of domain names are translated into IP addresses every day.

Next time a website is slow to load or doesn't resolve, you'll know exactly how to use dig to investigate. And if you're preparing for system design interviews, understanding this hierarchical delegation and caching system will give you deep insights into how the internet infrastructure works.

Happy digging!