How DNS Resolution Works: From `dig . NS` to Your Browser Loading Google

Every time you type google.com into a browser, something remarkable happens in milliseconds — a global, distributed lookup system translates that human-readable name into a machine-readable IP address. No single server handles this. No central database stores it all.

This is DNS, and understanding how it works will make you a sharper developer, a better debugger, and a more informed system designer.

In this article, we'll use the dig command to inspect each layer of DNS resolution, building a mental model from the ground up.

Why Name Resolution Exists

Computers communicate using IP addresses — numerical labels like 142.250.195.78. Every server on the internet has one. But humans don't think in IP addresses. We think in names.

DNS (Domain Name System) solves this mismatch. It's the protocol and infrastructure that translates google.com → 142.250.195.78 so your browser knows where to send its request.

What makes DNS interesting (and worth understanding deeply) is its architecture:

• Distributed — No single server holds all records. The system delegates responsibility across a global hierarchy.
• Cached — Responses are stored at multiple levels to reduce latency.
• Fault-tolerant — Each layer has multiple servers so no single failure breaks name resolution.

Meet dig — Your DNS Diagnostic Tool

dig (Domain Information Groper) is a command-line utility for querying DNS name servers. It ships with most Unix-like systems and is the go-to tool for DNS inspection.

Install it:

# macOS — usually pre-installed
dig --version

# Ubuntu / Debian
sudo apt install dnsutils

# CentOS / RHEL / Fedora
sudo yum install bind-utils

Basic syntax:

dig [domain] [record_type] [options]

Useful flags:

+short          # Concise output (just the answer)
+trace          # Full recursive trace from root down
@8.8.8.8        # Use a specific resolver
+norecurse      # Query the server directly without recursion

Now let's use dig to walk the DNS hierarchy from top to bottom.

The DNS Hierarchy at a Glance

Before commands, here's the architecture we're navigating:

                         ┌─────────────┐
                         │   Root NS   │  ← dig . NS
                         │  (. zone)   │
                         └──────┬──────┘
                                │ "Ask .com servers"
                         ┌──────▼──────┐
                         │   TLD NS    │  ← dig com NS
                         │ (.com zone) │
                         └──────┬──────┘
                                │ "Ask Google's servers"
                         ┌──────▼──────┐
                         │ Auth NS     │  ← dig google.com NS
                         │(google.com) │
                         └──────┬──────┘
                                │ "Here's the IP"
                         ┌──────▼──────┐
                         │  A Record   │  ← dig google.com
                         │142.250.x.x  │
                         └─────────────┘

DNS resolution is a top-down delegation chain. Each layer only knows how to refer you to the next. Let's explore each layer.

Layer 1: Root Name Servers — dig . NS

dig . NS

The . (dot) is the DNS root zone — the very top of the entire DNS hierarchy.

Output:

;; 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  m.root-servers.net.

There are 13 root name server names (a through m), but behind each name sit hundreds of physical servers globally — distributed via anycast routing. They're operated by a mix of organizations: ICANN, NASA, Verisign, Internet Systems Consortium, and others.

What they do: Root servers don't know the IP of google.com. They only know which servers are responsible for each Top-Level Domain (.com, .org, .net, .io, etc.).

The TTL of 518400 (6 days) tells you how stable these records are. Root server information almost never changes.

What NS records mean: An NS record points to the name server responsible for a DNS zone. Here, the root zone's NS records point to... the root servers themselves.

Layer 2: TLD Name Servers — dig com NS

dig com NS

Now we query the name servers for the .com TLD.

Output:

;; ANSWER SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
...
com.    172800  IN  NS  m.gtld-servers.net.

These are Verisign's gTLD (Generic Top-Level Domain) servers — responsible for the entire .com namespace. Over 160 million domain names fall under their jurisdiction.

What they do: When a recursive resolver asks "Who is authoritative for google.com?", the gTLD servers respond with Google's name server hostnames. They do not know Google's IP address directly — they only know who to ask next.

System Design Insight: This delegation model is what allows DNS to scale to billions of domains. No single database. No central authority below the root. Responsibility is partitioned and delegated hierarchically.

Layer 3: Authoritative Name Servers — dig google.com NS

dig google.com NS

Now we find the servers that actually own Google's DNS records.

Output:

;; 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.

These are Google's own authoritative name servers. Unlike the layers above them, these servers hold the actual DNS records:

Google runs its own infrastructure here. Many companies delegate this to DNS providers like Cloudflare, AWS Route 53, or Namecheap instead.

The TTL of 21600 (6 hours) is shorter than root/TLD records because these records can change — for example, when rotating infrastructure or updating configs.

The Full Resolution — dig google.com

dig google.com

This is the query your browser ultimately needs: "What's the IP address for google.com?"

Output:

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

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

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Breaking It Down

The Step-by-Step Flow (Uncached)

1. You type google.com
   ↓
2. Browser checks its DNS cache → miss
   ↓
3. OS checks /etc/hosts + system cache → miss
   ↓
4. Query sent to recursive resolver (8.8.8.8)
   ↓
5. Resolver asks Root NS: "Who handles .com?"
   ← "Ask a.gtld-servers.net"
   ↓
6. Resolver asks gTLD NS: "Who handles google.com?"
   ← "Ask ns1.google.com"
   ↓
7. Resolver asks ns1.google.com: "What's the A record for google.com?"
   ← "142.250.195.78, TTL 300"
   ↓
8. Resolver returns IP to your OS, caches it for 300 seconds
   ↓
9. Browser opens TCP connection to 142.250.195.78:443
   ↓
10. TLS handshake → HTTP request → Page loads ✓

The whole chain (steps 5–7) typically completes in under 100ms.

Recursive Resolvers: The Unsung Heroes

A recursive resolver is the server that does the work of traversing the hierarchy on your behalf. When you configure DNS on your router or device, you're pointing to a recursive resolver.

Your Device
    │
    ▼
Recursive Resolver (8.8.8.8)
    │  Checks its cache first...
    │  If miss, walks the chain:
    ├──► Root NS      → referral
    ├──► TLD NS       → referral
    └──► Auth NS      → answer ✓
         Caches the result
         Returns to you

Why Caching Matters

Every DNS response includes a TTL (Time to Live). Recursive resolvers cache answers for that duration before querying again.

Root NS TTLs      → ~2 days   (very stable)
TLD NS TTLs       → ~2 days   (very stable)
Auth NS TTLs      → hours     (occasionally updated)
A record TTLs     → seconds to hours (varies by domain)

This is why DNS changes take time to "propagate" — resolvers worldwide are still serving cached responses until TTLs expire. When you update a DNS record, it's fully live for everyone only after the old TTL has expired everywhere.

Popular Public Recursive Resolvers

8.8.8.8      → Google Public DNS
1.1.1.1      → Cloudflare DNS (fastest globally, strong privacy)
9.9.9.9      → Quad9 (security-focused, blocks malware domains)
208.67.222.222 → OpenDNS (Cisco)

Mapping dig Commands to DNS Stages

Here's a quick reference connecting each command to its role in the resolution flow:

dig . NS            # Stage 1: Who are the root name servers?
dig com NS          # Stage 2: Who manages the .com TLD?
dig google.com NS   # Stage 3: Who is authoritative for google.com?
dig google.com      # Stage 4: What's the actual IP address?

Or run them all at once with the trace flag:

dig +trace google.com

+trace makes dig itself walk the full hierarchy — from root to authoritative — and print every step. It's the most educational single command for understanding DNS resolution.

DNS in the Context of Real Browser Requests

When you visit https://google.com, DNS is step zero of the entire connection:

DNS Resolution       → ~1ms (cached) to ~100ms (fresh)
TCP Handshake        → ~10–50ms
TLS Handshake        → ~20–100ms
HTTP Request         → ~10–50ms
Page Render          → varies

DNS is often the fastest part once cached — but a cold DNS lookup on first visit adds real latency. This is why modern browsers implement:

• DNS prefetching — Pre-resolving domains found in <link rel="dns-prefetch"> or in page links
• Connection pre-warming — Opening TCP/TLS connections before the user clicks
• HTTP/3 with QUIC — Reduces connection overhead after DNS

And infrastructure teams use:

• Low TTLs (60–300s) on CDN records to route users to the nearest edge node
• DNS-based load balancing — Returning different IPs based on geography or health
• DNS-over-HTTPS (DoH) — Encrypting DNS queries so ISPs can't snoop on which sites you visit

Quick Reference Card

# The resolution hierarchy
dig . NS                    # Root name servers
dig com NS                  # .com TLD name servers
dig google.com NS           # Authoritative name servers
dig google.com              # Final A record (IPv4)

# Other record types
dig google.com AAAA         # IPv6 address
dig google.com MX           # Mail servers
dig google.com TXT          # TXT records (SPF, DKIM, verification)
dig google.com CNAME        # Canonical name alias

# Diagnostic flags
dig +short google.com       # Just the IP
dig +trace google.com       # Full resolution trace from root
dig @1.1.1.1 google.com    # Force a specific resolver
dig +norecurse @a.root-servers.net google.com  # Direct root query

Key Takeaways

• DNS is hierarchical and distributed. No single server knows everything — each layer delegates to the next.
• Root servers (. NS) point to TLD servers. There are 13 names, backed by hundreds of anycast servers.
• TLD servers (e.g., com NS) point to authoritative servers for each domain.
• Authoritative servers hold the actual records — A, MX, TXT, CNAME, etc.
• Recursive resolvers traverse the full chain on your behalf and cache results using TTLs.
• dig +trace is the fastest way to see the entire resolution chain in one command.

Resources

• IANA Root Zone Database
• RFC 1034 — Domain Names: Concepts and Facilities
• Cloudflare DNS Learning Center
• DNS Checker — Global Propagation Tool
• dns.google — Google's DNS over HTTPS UI

If this helped you build a clearer mental model of DNS, share it with your cohort. Understanding the infrastructure beneath the web makes you a better engineer at every layer of the stack.