DEV Community

sanjeev singh
sanjeev singh

Posted on

How DNS Resolution Works: A Deep Dive with `dig`

#beginners #cli #networking #tutorial

Have you ever wondered what happens between typing "google.com" in your browser and seeing the website appear? The answer lies in one of the internet's most critical yet invisible systems: the Domain Name System (DNS). In this article, we'll explore how DNS works by using the dig command to peek under the hood of internet name resolution.

What is DNS and Why Does Name Resolution Exist?

DNS (Domain Name System) is often called the "phonebook of the internet" – and for good reason. Just as a phonebook maps human-readable names to phone numbers, DNS maps domain names like google.com to IP addresses like 142.250.185.46.

Why Do We Need This?

Computers communicate using IP addresses – numerical labels like 192.168.1.1 (IPv4) or 2001:0db8:85a3::8a2e:0370:7334 (IPv6). While these are perfect for machines, they're terrible for humans to remember. Imagine having to memorize 142.250.185.46 every time you wanted to search something on Google!

DNS solves this problem by providing a distributed, hierarchical system that translates human-friendly domain names into machine-friendly IP addresses. This translation process is called name resolution.

Key Benefits of DNS

  1. Human-friendly: Easy to remember names instead of numeric addresses
  2. Flexibility: IP addresses can change without affecting the domain name
  3. Load balancing: Multiple IP addresses can be associated with one domain
  4. Service separation: Different services (web, email, FTP) can use different servers

What is the dig Command?

dig (Domain Information Groper) is a powerful command-line tool used to query DNS servers and inspect the DNS resolution process. It's an essential tool for:

  • Debugging DNS issues
  • Understanding how DNS works
  • Verifying DNS configurations
  • Troubleshooting network problems
  • Learning about DNS hierarchies

Basic Syntax 

dig [options] [domain] [query-type]
Enter fullscreen mode Exit fullscreen mode

Unlike tools like nslookup, dig provides detailed, human-readable output that shows exactly what's happening during DNS queries. Let's use it to explore the DNS hierarchy step by step.

Understanding DNS Hierarchy

Before we dive into specific dig commands, let's understand that DNS is organized as a hierarchical, tree-like structure with three main levels:

                    . (Root)
                     |
        +------------+------------+
        |            |            |
       com          org          net     ← TLD (Top-Level Domain)
        |
    +---+---+
    |       |
  google  amazon                         ← Second-Level Domain
    |
  www                                    ← Subdomain
Enter fullscreen mode Exit fullscreen mode

This hierarchy is crucial because DNS resolution works from top to bottom, querying each level to find the next one.

Step 1: Understanding dig . NS and Root Name Servers

Let's start at the very top of the DNS hierarchy: the root name servers.

The Command 

dig . NS
Enter fullscreen mode Exit fullscreen mode

What This Does

This command queries for the NS (Name Server) records of the root domain (represented by a single dot .). Root name servers are the foundation of the entire DNS system.

Sample Output 

; <<>> DiG 9.18.20 <<>> . 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.
Enter fullscreen mode Exit fullscreen mode

What This Means

There are 13 root name servers (labeled a through m) that form the foundation of DNS. These servers don't know the IP address of every website, but they know where to find the servers responsible for each top-level domain (TLD) like .com, .org, .net, etc.

Key Points:

  • The 518400 is the TTL (Time To Live) in seconds – about 6 days
  • NS records tell us which name servers are authoritative for a domain
  • These 13 root servers are replicated worldwide using anycast for redundancy
  • They're operated by different organizations for security and reliability

Step 2: Understanding dig com NS and TLD Name Servers

Now let's go one level down and query for the .com TLD name servers.

The Command 

dig com NS
Enter fullscreen mode Exit fullscreen mode

What This Does

This queries for the name servers responsible for the .com top-level domain.

Sample Output 

; <<>> DiG 9.18.20 <<>> 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.
Enter fullscreen mode Exit fullscreen mode

What This Means

The .com domain is managed by 13 "Generic Top-Level Domain" (gTLD) servers. These servers know about all domains registered under .com and can direct queries to the appropriate authoritative name servers for specific domains like google.com or amazon.com.

The Resolution Flow So Far:

Your Computer → Root Server → "For .com, ask the gTLD servers"
                              ↓
                     gTLD Servers (a-m.gtld-servers.net)
Enter fullscreen mode Exit fullscreen mode

Key Points:

  • TTL is 172800 seconds (2 days) – shorter than root servers
  • TLD servers are managed by registry operators (Verisign for .com)
  • Different TLDs have different operators (e.g., .org, .io, .dev)

Step 3: Understanding dig google.com NS and Authoritative Name Servers

Now let's query for the name servers that are authoritative for google.com specifically.

The Command 

dig google.com NS
Enter fullscreen mode Exit fullscreen mode

What This Does

This retrieves the authoritative name servers for the google.com domain – the servers that contain the actual DNS records for Google's domain.

Sample Output 

; <<>> DiG 9.18.20 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23456
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

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

;; 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
Enter fullscreen mode Exit fullscreen mode

What This Means

Google operates its own authoritative name servers (ns1 through ns4.google.com). These servers contain the definitive DNS records for all Google domains and subdomains.

The Complete Resolution Chain:

Your Computer → Root Server → "For .com, ask gTLD servers"
                              ↓
                     gTLD Server → "For google.com, ask ns1-4.google.com"
                                   ↓
                          Authoritative Servers (ns1-4.google.com)
                          (These have the actual A/AAAA records)
Enter fullscreen mode Exit fullscreen mode

Key Points:

  • The ADDITIONAL SECTION provides the IP addresses of the name servers (called "glue records")
  • This prevents a circular dependency problem (how would you find the IP of ns1.google.com if you need it to resolve google.com?)
  • Organizations can run their own name servers or use DNS hosting services

Step 4: Understanding dig google.com and the Full DNS Resolution Flow

Finally, let's perform a complete DNS lookup to get the IP address of google.com.

The Command 

dig google.com
Enter fullscreen mode Exit fullscreen mode

Sample Output 

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; 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 29 14:30:00 UTC 2026
;; MSG SIZE  rcvd: 55
Enter fullscreen mode Exit fullscreen mode

Breaking Down the Output

1. Header Section:

  • qr (Query Response): This is a response
  • rd (Recursion Desired): We asked for recursive resolution
  • ra (Recursion Available): The server supports recursion
  • NOERROR: The query was successful

2. Question Section:

  • Shows what we asked for: An A (IPv4 address) record for google.com

3. Answer Section:

  • google.com. 300 IN A 142.250.185.46
    • 300: TTL (Time to Live) – cache this for 5 minutes
    • IN: Internet class
    • A: Address record (IPv4)
    • 142.250.185.46: The actual IP address

4. Metadata:

  • Query took 23 milliseconds
  • Used server 8.8.8.8 (Google Public DNS) on port 53
  • Response size was 55 bytes

The Complete DNS Resolution Flow

Here's what happens behind the scenes when you run dig google.com:

┌─────────────────────┐
│   Your Computer     │
│   (Stub Resolver)   │
└──────────┬──────────┘
           │ 1. Query: What's the IP of google.com?
           ↓
┌─────────────────────┐
│  Recursive Resolver │  (e.g., 8.8.8.8, your ISP's DNS, or 1.1.1.1)
│  (Does the work)    │
└──────────┬──────────┘
           │ 2. Not in cache, let's find out...
           ↓
┌─────────────────────┐
│   Root Server       │  (a-m.root-servers.net)
│   (.)               │
└──────────┬──────────┘
           │ 3. Response: "For .com, ask gTLD servers"
           ↓
┌─────────────────────┐
│   TLD Server        │  (a-m.gtld-servers.net)
│   (.com)            │
└──────────┬──────────┘
           │ 4. Response: "For google.com, ask ns1-4.google.com"
           ↓
┌─────────────────────┐
│ Authoritative Server│  (ns1.google.com)
│ (google.com)        │
└──────────┬──────────┘
           │ 5. Response: "142.250.185.46"
           ↓
┌─────────────────────┐
│  Recursive Resolver │
│  (Caches result)    │
└──────────┬──────────┘
           │ 6. Returns: "142.250.185.46"
           ↓
┌─────────────────────┐
│   Your Computer     │
│   (Connects to IP)  │
└─────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Tracing the Full Resolution

To see this process in action, you can use the +trace option:

dig +trace google.com
Enter fullscreen mode Exit fullscreen mode

This shows each step of the resolution process, querying root servers, TLD servers, and finally authoritative servers.

Understanding NS Records and Why They Matter

NS (Name Server) records are fundamental to DNS because they create the delegation chain. Each level of the DNS hierarchy uses NS records to point to the next level.

What NS Records Do

  1. Delegation: They delegate responsibility for a domain to specific name servers
  2. Redundancy: Multiple NS records provide backup servers
  3. Load Distribution: Different queries can go to different name servers
  4. Hierarchy Navigation: They create the path from root to final answer

Example Delegation Chain 

. (root)
  → NS: a.root-servers.net (and 12 others)
    → com.
      → NS: a.gtld-servers.net (and 12 others)
        → google.com.
          → NS: ns1.google.com (and 3 others)
            → www.google.com.
              → A: 142.250.185.46
Enter fullscreen mode Exit fullscreen mode

How Recursive Resolvers Use This Information

When you configure your computer to use a DNS server like 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), or your ISP's DNS server, you're using a recursive resolver. Here's what it does:

The Recursive Resolver's Job

  1. Receives your query: "What's the IP for google.com?"
  2. Checks its cache: Has it resolved this recently?
  3. If not cached, performs iterative queries:
    • Queries a root server
    • Queries the appropriate TLD server
    • Queries the authoritative server
  4. Caches the result: Based on the TTL value
  5. Returns the answer: To your computer

Caching is Critical

Notice the different TTL values we saw:

  • Root servers: 518400 seconds (~6 days)
  • TLD servers: 172800 seconds (~2 days)
  • google.com A record: 300 seconds (~5 minutes)

Google uses a short TTL for their A records because:

  • They can quickly update IP addresses
  • They can redirect traffic for load balancing
  • They can respond to outages faster

Connecting DNS to Real-World Browser Requests

Let's tie this all together with what happens when you type https://www.google.com in your browser:

Step-by-Step Browser Flow 

1. Browser checks its cache
   ↓ (if not found)
2. OS checks its cache
   ↓ (if not found)
3. OS queries configured DNS resolver (e.g., 8.8.8.8)
   ↓
4. Recursive resolver performs full DNS resolution
   (as we explored with dig)
   ↓
5. Resolver returns IP: 142.250.185.46
   ↓
6. Browser initiates TCP connection to 142.250.185.46:443
   ↓
7. TLS handshake occurs
   ↓
8. HTTPS request is sent
   ↓
9. Web page is returned
Enter fullscreen mode Exit fullscreen mode

Performance Implications

DNS resolution is often overlooked but critical for performance:

  • First visit: Full DNS resolution required (~20-100ms)
  • Cached visits: Nearly instant (<1ms)
  • DNS prefetching: Browsers can resolve domains before you click links
  • HTTP/2 & HTTP/3: Reduce the impact by reusing connections

DNS and System Design

For system designers and engineers, DNS is more than just name resolution:

Load Balancing:

dig www.google.com
# Often returns multiple A records
# Clients pick one (usually round-robin)
Enter fullscreen mode Exit fullscreen mode

Geographic Distribution:

  • Different users may get different IPs based on location
  • Achieved through GeoDNS/Anycast

Service Discovery:

  • SRV records can specify ports and priorities
  • Used in microservices architectures

Failover:

  • Low TTLs allow quick IP changes during outages
  • Health checks can update DNS records automatically

Practical DNS Commands Cheat Sheet

Here are some useful dig variations:

# Get IPv6 address (AAAA record)
dig google.com AAAA

# Get mail server records
dig google.com MX

# Get all records
dig google.com ANY

# Reverse DNS lookup (IP to domain)
dig -x 142.250.185.46

# Use specific DNS server
dig @8.8.8.8 google.com

# Short answer only
dig google.com +short

# Trace full resolution path
dig +trace google.com

# No caching (ask authoritative server directly)
dig google.com +norecurs
Enter fullscreen mode Exit fullscreen mode

Common DNS Record Types

Beyond the A and NS records we've discussed:

Record Type Purpose Example
A IPv4 address google.com → 142.250.185.46
AAAA IPv6 address google.com → 2607:f8b0:4004:c07::71
NS Name server google.com → ns1.google.com
MX Mail server google.com → smtp.google.com
CNAME Canonical name (alias) www → google.com
TXT Text records SPF, DKIM, verification
SRV Service locator _service._proto.domain
SOA Start of Authority Zone metadata

Conclusion

DNS is a beautifully designed distributed system that powers the modern internet. By using dig, we've explored:

  1. Root name servers (.) – The foundation of DNS
  2. TLD name servers (com) – Managing top-level domains
  3. Authoritative name servers (ns1.google.com) – The source of truth
  4. Full resolution (google.com) – Tying it all together

The hierarchical nature of DNS provides:

  • Scalability: Billions of domains can be resolved
  • Decentralization: No single point of failure
  • Flexibility: Domains can be managed independently
  • Performance: Caching at multiple levels

Next time you visit a website, you'll know that before your browser can even start loading the page, an elegant chain of DNS queries has already occurred – from the root of the internet's namespace tree all the way down to the specific IP address you need.

Top comments (0)