How DNS Resolution Works: A Step-by-Step Journey with dig

When you type google.com in your browser, something magical happens behind the scenes. Your computer doesn't actually know where Google lives — it has to ask around. This process is called DNS resolution, and understanding it will give you powerful insight into how the internet really works.

Introduction

In the previous article, we learned about DNS record types. Now let's see them in action! We'll trace the exact journey your computer takes to find a website's address.

DNS (Domain Name System) is the internet's phonebook. But unlike a simple phonebook lookup, DNS resolution happens in layers — like asking a series of people until you find someone who knows the exact address.

We'll use a powerful tool called dig to inspect each step of this process. By the end, you'll understand exactly how your browser finds any website on the internet.

Prerequisites

• Basic understanding of DNS and record types (A, NS records)

• Access to a terminal (Linux, macOS, or WSL on Windows)

• dig command installed (comes with dnsutils or bind-utils package)

To check if dig is installed:

dig -v

If not installed:

# Ubuntu/Debian
sudo apt install dnsutils

# macOS (comes pre-installed)

# Windows (use WSL or install BIND)

---

What is DNS Resolution?

DNS resolution (or "name resolution") is the process of converting a human-readable domain name into an IP address that computers can use.

Why Does Name Resolution Exist?

Computers communicate using IP addresses like 142.250.193.206. But humans can't remember these numbers for every website they visit. DNS bridges this gap:

Human types:    google.com
DNS resolves:   google.com → 142.250.193.206
Browser uses:   142.250.193.206

The Resolution Journey

DNS resolution doesn't happen in one step. It's a hierarchical process that queries multiple servers:

Your Computer
      ↓
Recursive Resolver (usually your ISP)
      ↓
Root Name Servers (.)
      ↓
TLD Name Servers (.com, .org, .net)
      ↓
Authoritative Name Servers (google.com)
      ↓
IP Address Returned!

Let's explore each layer using the dig command.

---

What is the dig Command?

dig (Domain Information Groper) is a command-line tool for querying DNS servers. It's like having X-ray vision into DNS — you can see exactly what's happening during resolution.

Basic Syntax

dig [name] [record-type]

Simple Example

dig google.com

This queries the DNS for google.com and shows you the A record (IP address).

Why Use dig?

💡 Tip: dig is the go-to tool for DNS troubleshooting. Every developer and sysadmin should know how to use it!

---

Understanding the DNS Hierarchy

Before we dive into commands, let's visualize the DNS hierarchy. It's structured like an upside-down tree:

                         . (Root)
                         │
         ┌───────────────┼───────────────┐
         │               │               │
        com             org             net     ← TLD (Top-Level Domain)
         │               │               │
    ┌────┼────┐         │          ┌────┼────┐
    │    │    │         │          │    │    │
 google amazon ebay  wikipedia  cloudflare github
    │
┌───┴───┐
│       │
www    mail                              ← Subdomains

The Three Levels of Name Servers

1. Root Name Servers (.): The starting point of all DNS queries

2. TLD Name Servers (.com, .org): Handle top-level domains

3. Authoritative Name Servers: Know the actual IP addresses for specific domains

Let's query each level!

---

Step 1: Root Name Servers (dig . NS)

The root name servers are the top of the DNS hierarchy. They don't know where google.com is, but they know who to ask next.

The Command

dig . NS

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

The 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      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 Means

There are 13 root server addresses (a through m), operated by various organizations worldwide. These are the starting point for ALL DNS queries.

ℹ️ Note: The number 13 is a technical limitation due to the size of a DNS UDP packet. However, each "server" is actually a cluster of many servers distributed globally using Anycast.

Understanding the Output Format

.    518400    IN    NS    a.root-servers.net.
│       │       │     │              │
│       │       │     │              └── The nameserver address
│       │       │     └── Record type (NS = Name Server)
│       │       └── Class (IN = Internet)
│       └── TTL (Time To Live in seconds)
└── Domain being queried (. = root)

---

Step 2: TLD Name Servers (dig com NS)

Next, let's find who handles the .com top-level domain.

The Command

dig com NS

This asks: "Who are the name servers for the .com TLD?"

The Output

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

The gTLD servers (generic Top-Level Domain servers) handle all .com domains. When asked about google.com, they don't know the IP address, but they know which nameservers are authoritative for google.com.

TLD Examples

---

Step 3: Authoritative Name Servers (dig google.com NS)

Now let's find who has the final authority over google.com.

The Command

dig google.com NS

This asks: "Who are the authoritative name servers for google.com?"

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

What This Means

Google runs their own nameservers (ns1.google.com through ns4.google.com). These are the authoritative sources for all DNS records under google.com.

When you ask these servers about google.com, they give you the definitive answer — the actual IP address.

Why NS Records Matter

NS records form the delegation chain:

• Root servers delegate .com to gTLD servers

• gTLD servers delegate google.com to Google's nameservers

• Google's nameservers have the actual A records

Who handles .?        → Root servers
Who handles .com?     → gTLD servers
Who handles google.com? → ns1.google.com (Google's servers)
What's the IP of google.com? → 142.250.193.206

---

Step 4: The Full Resolution (dig google.com)

Finally, let's get the actual IP address!

The Command

dig google.com

The Output

; <<>> DiG 9.16.1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; 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.193.206

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jan 31 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 55

Breaking Down the Output

Header Section:

status: NOERROR     ← Query was successful
flags: qr rd ra     ← Query Response, Recursion Desired, Recursion Available

Question Section:

;google.com.    IN    A

"What is the A record for google.com?"

Answer Section:

google.com.    300    IN    A    142.250.193.206

The IP address is 142.250.193.206 with a TTL of 300 seconds (5 minutes).

Additional Info:

Query time: 23 msec           ← How long the query took
SERVER: 192.168.1.1#53        ← Which DNS server answered (your router/ISP)

💡 Tip: The low TTL (300 seconds) means Google can change their IP addresses frequently, and clients will pick up changes within 5 minutes.

---

The Complete DNS Resolution Flow

Let's put it all together. When you type google.com in your browser:

┌──────────────────────────────────────────────────────────────────┐
│                    DNS Resolution for google.com                  │
└──────────────────────────────────────────────────────────────────┘

Step 1: Your Browser
        │
        │ "What's the IP for google.com?"
        ▼
Step 2: Recursive Resolver (Your ISP or 8.8.8.8)
        │
        │ Checks cache → Not found
        │ "I'll find out for you"
        ▼
Step 3: Root Servers (.)
        │
        │ "I don't know google.com, but .com is handled by
        │  a.gtld-servers.net"
        ▼
Step 4: TLD Servers (.com)
        │
        │ "I don't know google.com's IP, but it's managed by
        │  ns1.google.com"
        ▼
Step 5: Authoritative Servers (ns1.google.com)
        │
        │ "google.com is at 142.250.193.206"
        ▼
Step 6: Recursive Resolver
        │
        │ Caches the result
        │ Returns to browser
        ▼
Step 7: Your Browser
        │
        │ Connects to 142.250.193.206
        ▼
Step 8: Google's Server responds! 🎉

See It Live with +trace

You can watch this entire process with one command:

dig +trace google.com

This shows you every step of the resolution, from root servers to final answer!

---

How Recursive Resolvers Work

You might wonder: "Does my browser really query all these servers every time?"

No! That's where recursive resolvers come in.

What is a Recursive Resolver?

A recursive resolver is a DNS server that does all the hard work for you. When you make a DNS query:

1. Your computer asks the recursive resolver

2. The resolver checks its cache first

3. If not cached, it queries root → TLD → authoritative servers

4. It caches the result for future queries

5. Returns the answer to you

Common Recursive Resolvers

Query a Specific Resolver

# Use Google's DNS
dig @8.8.8.8 google.com

# Use Cloudflare's DNS
dig @1.1.1.1 google.com

Caching Saves Time

First query:   Browser → Resolver → Root → TLD → Auth → Response (100ms)
Second query:  Browser → Resolver (cached) → Response (5ms)

The resolver caches responses based on TTL, making subsequent queries much faster.

┌────────────────────────────────────────────────────────────────┐
│                    Recursive Resolver                          │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│   ┌─────────────────────────────────────────┐                  │
│   │             Cache                        │                  │
│   │  google.com → 142.250.193.206 (TTL:300) │                  │
│   │  github.com → 140.82.121.4   (TTL:60)   │                  │
│   │  ...                                     │                  │
│   └─────────────────────────────────────────┘                  │
│                         │                                       │
│            Cache Hit?   │                                       │
│           ┌─────────────┴─────────────┐                        │
│           ▼                           ▼                        │
│         Yes                          No                        │
│           │                           │                        │
│     Return cached              Query hierarchy                 │
│        result                 (Root→TLD→Auth)                  │
│                                       │                        │
│                              Cache & Return                    │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

---

Connecting It All to Browser Requests

Let's see how this relates to real-world browsing.

What Happens When You Visit google.com

1. You type "google.com" and press Enter

2. Browser checks its own DNS cache
   └── Not found? Continue...

3. OS checks its DNS cache (/etc/hosts, system cache)
   └── Not found? Continue...

4. OS asks the configured recursive resolver (e.g., 8.8.8.8)

5. Resolver performs the resolution we traced:
   └── Root → TLD → Authoritative → IP Address

6. IP address (142.250.193.206) returned to browser

7. Browser establishes TCP connection to 142.250.193.206

8. Browser sends HTTP request: GET / HTTP/1.1

9. Google's server responds with the webpage

10. Browser renders the page — you see Google!

The dig Commands Map to Resolution Stages

---

Useful dig Commands Reference

# Basic A record lookup
dig example.com

# Query specific record type
dig example.com NS       # Nameservers
dig example.com MX       # Mail servers
dig example.com TXT      # Text records
dig example.com AAAA     # IPv6 address

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

# Query a specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Short output (just the answer)
dig +short example.com

# Reverse lookup (IP to domain)
dig -x 142.250.193.206

# Get all records
dig example.com ANY

---

Best Practices

• Use dig +trace for debugging — It shows the complete resolution path

• Check TTL values — Low TTLs mean frequent re-resolution

• Query different resolvers — Helps identify caching or propagation issues

• Understand the hierarchy — Root → TLD → Authoritative is always the flow

• Use +short for quick answers — dig +short google.com gives just the IP

Common Issues and Debugging

---

Conclusion

You've now traced the complete journey of DNS resolution! Here's what we learned:

• DNS resolution converts domain names to IP addresses through a hierarchical process

• dig is a powerful tool for inspecting DNS at every level

• Root servers (.) are the starting point, directing to TLD servers

• TLD servers (.com) direct to authoritative nameservers

• Authoritative servers have the final answer (the actual IP)

• Recursive resolvers do this work for you and cache results

• Every browser request depends on this resolution happening first

Understanding DNS resolution helps you debug issues, design systems, and appreciate the infrastructure that makes the internet work.

Next Steps / Further Reading

• Practice with dig +trace on different domains

• Learn about DNSSEC (DNS Security Extensions)

• Explore DNS over HTTPS (DoH) and DNS over TLS (DoT)

• Set up your own DNS server with Pi-hole or BIND

---

If you found this helpful, consider following for more deep dives into web infrastructure and networking.