DNS Resolution with dig: Understanding the Internet's Phonebook

DNS translates domain names to IP addresses. Instead of memorizing 172.217.0.46, you visit google.com. But how does this translation actually work? Enter dig - the DNS investigator tool.

What is dig?

dig (Domain Information Groper) is a command-line tool that queries DNS servers directly. While browsers hide DNS complexity, dig reveals the step-by-step resolution process. Use it to:

• Debug DNS configuration issues

• Verify DNS record changes

• Understand DNS hierarchy and delegation

• Learn how internet name resolution actually works

The DNS Hierarchy: A Layered System

DNS resolution works in three layers:

Root Servers (.)
     ↓ directs to
TLD Servers (.com, .org, .net)
     ↓ directs to
Authoritative Servers (google.com, example.com)

Each layer knows only about the next layer down. Let's trace this with dig.

Step 1: Querying Root Servers

The root servers are the starting point- they know who manages each Top-Level Domain (TLD).

dig . NS

**
What this shows:**

• a.root-servers.net. through m.root-servers.net.

• These 13 root server clusters (actually hundreds of instances globally)

• Why it matters: Every DNS resolution starts here, or with cached root data

Output interpretation:

;; ANSWER SECTION:
.            518400    IN    NS    a.root-servers.net.
.            518400    IN    NS    b.root-servers.net.
... (11 more)

Root servers don't know about google.com—they only know about TLDs like .com.

Step 2: Querying TLD Servers

Each Top-Level Domain has its own nameservers. For .com:

dig com. NS

What this shows:

• Who manages the .com TLD

• Why it matters: TLD servers know who owns each domain in their namespace

Output interpretation:

;; ANSWER SECTION:
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
... (11 more)

These .com nameservers know about all .com domains but don't store their IPs—they only know which authoritative servers manage each domain.

Step 3: Finding Authoritative Nameservers

Authoritative servers hold the actual DNS records for a domain:

dig google.com NS

What this shows:

• The specific nameservers responsible for google.com

• Why it matters: These servers have the final answer for all google.com queries

Output interpretation:

;; ANSWER SECTION:
google.com.        345600    IN    NS    ns1.google.com.
google.com.        345600    IN    NS    ns2.google.com.
... (2 more)

;; ADDITIONAL SECTION:
ns1.google.com.        345600    IN    A    216.239.32.10
ns2.google.com.        345600    IN    A    216.239.34.10

Note the ADDITIONAL SECTION—it provides IPs for these nameservers, preventing chicken-and-egg problems.

Step 4: The Final Resolution

Now we ask the authoritative servers directly:

dig google.com

What happens here:

1. Your system's resolver checks local cache

2. If not cached, resolver queries root servers (or uses cached root data)

3. Root directs to .com TLD servers

4. TLD directs to google.com authoritative servers

5. Authoritative server returns the actual A/AAAA records

Output interpretation:

;; ANSWER SECTION:
google.com.        300    IN    A    142.250.74.46
google.com.        300    IN    AAAA    2607:f8b0:4004:c07::8e

The 300 is TTL (Time to Live) in seconds—how long resolvers should cache this answer.

How Browsers Actually Use This

When you visit google.com:

1. The browser asks the OS, "What's the IP for google.com?"

2. OS resolver (often using cached results) performs the hierarchical lookup:

   • Check the cache for google.com A record

   • If not cached, query configured recursive resolver (like 8.8.8.8)

   • Recursive resolver performs the full root → TLD → authoritative lookup

   • Returns the final IP to the OS, which caches it

3. The browser receives the IP address, establishes a TCP connection to 142.250.74.46:443

4. The browser sends an HTTP request over an established connection

Your recursive resolver (ISP, Google DNS, Cloudflare DNS) does the heavy lifting—caching results at each layer for efficiency.

Practical dig Usage Examples

# Trace the full resolution path
dig +trace google.com

# Query specific DNS server (bypass local resolver)
dig @8.8.8.8 google.com

# Get only the IP (useful for scripting)
dig +short google.com

# Query specific record types
dig google.com MX      # Mail servers
dig google.com TXT     # Text records (SPF, DKIM)
dig google.com AAAA    # IPv6 address

Common DNS Resolution Patterns

Cached resolution (typical case):

Browser → OS Resolver (cache check) → Return cached IP

Full recursive resolution (cache miss):

Browser → OS Resolver → Recursive Resolver → Root → TLD → Authoritative → Return IP

Direct authoritative query (with dig @ns1.google.com):

dig → Authoritative Server → Return IP

Why This Matters for Developers

Understanding DNS resolution helps with:

1. Debugging: When users can't reach your site, check DNS first

2. Performance: Lower TTLs for changes, higher for stability

3. Migration: Update NS records before moving servers

4. Security: DNSSEC validation follows this same hierarchy

5. Infrastructure: Multi-CDN and load balancing rely on DNS

Remember: DNS is globally cached. Changes propagate at TTL speed, not instantly. A 300-second TTL means some users see old data for up to 5 minutes after changes.

Next time your browser loads a website, remember the invisible journey: root → TLD → authoritative → IP. That's the DNS hierarchy dig reveals—the backbone of human-friendly internet navigation.

Enjoyed this guide? Let's connect!
🐦 Twitter/X: @rohan_gupta96
💼 LinkedIn: https://www.linkedin.com/in/rohangupta9896
🐙 GitHub: https://github.com/rohan9896