Home/Learn/Computer Networks/How DNS Resolution Works

How DNS Resolution Works

Intermediate
Interview Patterns

DNS resolution converts a human-readable hostname into an IP address through a hierarchy of caches and authoritative nameservers — from browser cache to root nameservers and back in milliseconds.

Overview

DNS (Domain Name System) is one of the internet's most critical infrastructure components. A query for "api.aicancode.org" traverses: browser cache → OS cache → recursive resolver → root nameserver → TLD nameserver → authoritative nameserver. Each layer has a TTL that controls caching duration. DNS supports multiple record types (A, AAAA, CNAME, MX, TXT, NS, SRV), load balancing strategies (round-robin, weighted, geo-routing), and security extensions (DNSSEC). Modern DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries to prevent eavesdropping.

Iterative vs Recursive Resolution

A stub resolver (in the OS) sends a recursive query to a recursive resolver (e.g. 8.8.8.8) — asking it to fully resolve the name. The recursive resolver performs iterative queries: it contacts each nameserver in the hierarchy in turn, each one referring it to the next, until it reaches the authoritative nameserver that holds the final answer.

Iterative DNS resolution walkthrough
// DNS query path for "api.aicancode.org" (full cache miss):
//
// Browser → OS stub resolver: "What is api.aicancode.org?"
// OS stub resolver → Recursive resolver (8.8.8.8): "Resolve api.aicancode.org"
//
// Recursive resolver performs ITERATIVE queries:
//
// Step 1: Ask Root NS (.)
//   Query:  "api.aicancode.org"  → Root NS 198.41.0.4
//   Answer: "I don't know, ask .org TLD NS at 199.19.56.1"
//
// Step 2: Ask .org TLD NS
//   Query:  "api.aicancode.org"  → 199.19.56.1
//   Answer: "I don't know, ask aicancode.org NS at ns1.vercel-dns.com"
//
// Step 3: Ask aicancode.org Authoritative NS
//   Query:  "api.aicancode.org"  → ns1.vercel-dns.com
//   Answer: "api.aicancode.org A 76.76.21.21  TTL=300"
//
// Recursive resolver caches the A record for 300s, returns to OS, OS returns to browser
// Total time: ~50–100ms on first query; ~0ms on cache hit

DNS Record Types

DNS supports many record types. A/AAAA map hostnames to IPv4/IPv6 addresses. CNAME is an alias — it points to another hostname, not an IP. MX records route email. TXT records hold arbitrary text (SPF, DKIM, domain ownership verification). SRV records provide service discovery with port and priority.

DNS record types with examples
// Common DNS record types:
// A     — hostname → IPv4 address
api.aicancode.org.  300  IN  A  76.76.21.21

// AAAA  — hostname → IPv6 address
api.aicancode.org.  300  IN  AAAA  2606:4700::6810:1515

// CNAME — alias → another hostname (cannot coexist with other records at apex)
www.aicancode.org.  300  IN  CNAME  aicancode.org.   // ← resolves aicancode.org next

// MX    — mail exchange (priority + mail server)
aicancode.org.  300  IN  MX  10  mail.google.com.   // priority 10

// TXT   — arbitrary text (SPF, DKIM, site verification)
aicancode.org.  300  IN  TXT  "v=spf1 include:_spf.google.com ~all"

// NS    — nameservers for the zone
aicancode.org.  86400  IN  NS  ns1.vercel-dns.com.
aicancode.org.  86400  IN  NS  ns2.vercel-dns.com.

// SRV   — service discovery (proto, priority, weight, port, target)
_grpc._tcp.api.aicancode.org.  300  IN  SRV  10 100 443 grpc.aicancode.org.

TTL, Negative Caching & Propagation

TTL (Time to Live) controls how long a DNS record is cached at each resolver. Low TTL (60s) enables fast failover but increases query load. High TTL (86400s) reduces load but delays updates. Negative caching (NXDOMAIN TTL from SOA) caches "domain not found" responses to avoid hammering nameservers for non-existent records.

TTL strategy and DNS propagation timing
// TTL strategy:
// Normal operation: TTL=300 (5 min) — balance between caching and flexibility
// Before planned change (IP migration, failover):
//   Lower TTL 48h in advance: TTL=60
//   Make the DNS change → propagates in ~60s
//   After: restore TTL=300

// DNS propagation is NOT instant:
// Each resolver caches for TTL seconds independently
// During TTL window, some resolvers return old IP, some new
// Solution: lower TTL BEFORE change, not after

// Negative caching (SOA MINIMUM):
$ORIGIN aicancode.org.
@  IN  SOA  ns1.vercel-dns.com. admin.aicancode.org. (
       2026041301  ; serial
       3600        ; refresh
       900         ; retry
       604800      ; expire
       300         ; minimum (negative cache TTL)
)
// NXDOMAIN "api-nonexistent.aicancode.org" cached for 300s

// Check DNS propagation:
dig api.aicancode.org @8.8.8.8 +short        // Google resolver
dig api.aicancode.org @1.1.1.1 +short        // Cloudflare resolver
dig api.aicancode.org @ns1.vercel-dns.com +short  // authoritative

DNS-Based Load Balancing & Geo-Routing

DNS can distribute traffic before any load balancer is involved. Round-robin DNS returns multiple A records (browser picks one). Weighted routing assigns proportional traffic. Latency-based routing returns the IP of the nearest healthy region. This is how AWS Route 53, Cloudflare, and Fastly implement global traffic steering.

DNS-based load balancing and geo-routing with Route 53
// Round-robin DNS (simple):
api.aicancode.org.  60  A  10.0.1.1
api.aicancode.org.  60  A  10.0.1.2
api.aicancode.org.  60  A  10.0.1.3
// Different resolvers cache different subsets → approximate load distribution

// AWS Route 53 — Latency-based routing:
resource "aws_route53_record" "api_us" {
  zone_id = var.zone_id
  name    = "api.aicancode.org"
  type    = "A"
  set_identifier = "us-east-1"
  latency_routing_policy { region = "us-east-1" }
  alias { name = aws_lb.us.dns_name; zone_id = aws_lb.us.zone_id }
}
resource "aws_route53_record" "api_ap" {
  // same name, different region → Route 53 returns closest
  latency_routing_policy { region = "ap-south-1" }
  alias { name = aws_lb.ap.dns_name; zone_id = aws_lb.ap.zone_id }
}

// Route 53 health checks — automatic failover:
// If us-east-1 health check fails, Route 53 stops returning that record
// All traffic automatically routes to ap-south-1

Key Points to Remember

  • 1A recursive resolver does the heavy lifting — stub resolvers ask it once, and it iterates through root → TLD → authoritative nameservers.
  • 2CNAME cannot coexist with other records at the zone apex — use ALIAS records (Route 53) or ANAME for root domain CDN/LB pointing.
  • 3Lower TTL 48 hours before any planned DNS change; high TTL during normal operation reduces query load.
  • 4DNS-based load balancing (round-robin, latency-based, weighted) routes at the resolver level — before TCP is even opened.
  • 5Route 53 health checks + failover routing provide automatic DNS-level failover when a regional endpoint goes down.

Interview Questions

Sign in to ask Aria
1

Explain the full DNS resolution process for a domain with no caching.

MediumAmazon
2

What is the difference between a CNAME and an A record? When can you not use a CNAME?

MediumThoughtWorks
3

Why should you lower TTL before a DNS change, not after?

MediumRazorpay
4

How does Route 53 latency-based routing work and how does it differ from round-robin DNS?

HardFlipkart
5

What is negative caching in DNS and why does it exist?

HardEqual Experts

Ask Aria about How DNS Resolution Works

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Sign in to save personal notes for this topic.

Discussion

Sign in to join the discussion.

Loading discussion…