DEV Community

Cover image for How DNS Resolution Works
Mohd Asif Ansari
Mohd Asif Ansari

Posted on

How DNS Resolution Works

#webdev #beginners #networking #dns

Ever wondered what happens when you type "google.com" and hit enter? Let's find out using a tool called dig.

What is DNS?

DNS (Domain Name System) is the internet's phonebook.

Computers use IP addresses (like 142.250.192.46), but we prefer names like "google.com".

DNS translates names to IP addresses.

The dig Command

dig (Domain Information Groper) lets you see exactly how DNS works.

Basic use:

dig example.com
Enter fullscreen mode Exit fullscreen mode

This asks "what's the IP for example.com?"

DNS Works in Layers

DNS is organized in three layers:

Root Servers (.)
    ↓
TLD Servers (.com, .org, .net)
    ↓
Authoritative Servers (google.com, facebook.com)
Enter fullscreen mode Exit fullscreen mode

When you look up "google.com":

  1. Ask root servers: "Who handles .com?"
  2. Ask .com servers: "Who handles google.com?"
  3. Ask google.com servers: "What's the IP?"

Let's see this with dig.

Step 1: Root Name Servers

Command:

dig . NS
Enter fullscreen mode Exit fullscreen mode

Asks: "Who are the root name servers?"

Output:

.    IN  NS  a.root-servers.net.
.    IN  NS  b.root-servers.net.
...
Enter fullscreen mode Exit fullscreen mode

What this means:

  • The . is the DNS root
  • 13 root server systems (a through m)
  • They know about all TLDs (.com, .org, etc.)

Key point: Root servers don't know websites. They just direct you to the right TLD.

Step 2: TLD Name Servers

Command:

dig com NS
Enter fullscreen mode Exit fullscreen mode

Asks: "Who handles .com domains?"

Output:

com.  IN  NS  a.gtld-servers.net.
com.  IN  NS  b.gtld-servers.net.
...
Enter fullscreen mode Exit fullscreen mode

What this means:

  • These manage all .com domains
  • They know which servers handle each .com domain

Key point: TLD servers say "for google.com, ask Google's servers"

Step 3: Authoritative Name Servers

Command:

dig google.com NS
Enter fullscreen mode Exit fullscreen mode

Asks: "Who are the authoritative servers for google.com?"

Output:

google.com.  IN  NS  ns1.google.com.
google.com.  IN  NS  ns2.google.com.
...
Enter fullscreen mode Exit fullscreen mode

What this means:

  • These are Google's DNS servers
  • They have the actual records
  • They're the final source of truth

Key point: Authoritative servers have the real IP addresses.

Step 4: Full Resolution

Command:

dig google.com
Enter fullscreen mode Exit fullscreen mode

Asks: "What's the IP for google.com?"

Output:

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

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

;; Query time: 23 msec
Enter fullscreen mode Exit fullscreen mode

Breaking it down:

  • Question: What's google.com's IP?
  • Answer: 142.250.192.46
  • Time: 23 milliseconds

Complete DNS Resolution Flow

Here's what happens behind the scenes:

1. Your computer asks DNS resolver (8.8.8.8):
   "What's google.com?"

2. Resolver asks root server:
   "Where are .com servers?"

3. Resolver asks TLD server:
   "Where are google.com servers?"

4. Resolver asks authoritative server:
   "What's the IP?"
   Answer: "142.250.192.46"

5. Your browser connects to that IP
Enter fullscreen mode Exit fullscreen mode

Visual flow:

Your Computer
    ↓
DNS Resolver (8.8.8.8)
    ↓
Root Server (.)
    ↓
TLD Server (.com)
    ↓
Authoritative Server (ns1.google.com)
    ↓
Returns IP to Your Computer
Enter fullscreen mode Exit fullscreen mode

Recursive Resolver

The recursive resolver (like 8.8.8.8) does all the work:

  • Takes your DNS query
  • Asks root, TLD, and authoritative servers
  • Caches results
  • Returns the final answer

You ask once. The resolver handles everything.

DNS Caching Makes It Fast

DNS caches at multiple levels:

  1. Browser cache
  2. OS cache
  3. DNS resolver cache
  4. ISP cache

Example:

First visit: Root → TLD → Authoritative (~50ms)
Second visit: Cached! (~1ms)
Enter fullscreen mode Exit fullscreen mode

That's why repeat visits are faster.

Practical dig Examples

Basic lookup:

dig google.com
Enter fullscreen mode Exit fullscreen mode

Use specific DNS server:

dig @8.8.8.8 google.com
Enter fullscreen mode Exit fullscreen mode

Trace full path:

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

Get just the IP:

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

Check email servers:

dig google.com MX
Enter fullscreen mode Exit fullscreen mode

What Are NS Records?

NS (Name Server) records say "this server has authority for this domain"

Chain of trust:

Root: "For .com, trust these TLD servers"
TLD: "For google.com, trust these authoritative servers"
Authoritative: "Here's the actual IP"
Enter fullscreen mode Exit fullscreen mode

Real Browser Flow

When you visit a website:

  1. Browser checks cache
  2. OS checks cache
  3. DNS resolver checks cache
  4. If no cache: root → TLD → authoritative
  5. Browser gets IP
  6. Connects and loads page

Happens in milliseconds!

Why Developers Need This

Debugging: Use dig to check DNS issues

Performance: Understand caching to reduce latency

Deployment: Know DNS propagation when changing records

Interviews: DNS is a common system design question

Quick Summary

DNS Hierarchy:

  • Root → Know about TLDs
  • TLD → Know about domains
  • Authoritative → Have actual IPs

Commands:

  • dig . NS → Root servers
  • dig com NS → TLD servers
  • dig google.com NS → Authoritative servers
  • dig google.com → Get IP

Flow:
Your computer → Resolver → Root → TLD → Authoritative → Back with IP

Key Points:

  • NS records point to name servers
  • Resolvers do the work
  • Caching makes it fast
  • Each layer delegates to the next

Now you know exactly what happens when you visit a website!

Top comments (0)