system-design · beginner

DNS — Domain Name System Resolution and Caching

The Central Question

Consider a web application deployed on a cloud virtual machine with public IP address 203.0.113.10.

If users were forced to type http://203.0.113.10 into their web browsers, two major problems would occur:

1. Humans cannot memorize numeric IP addresses for dozens of services.
2. If the server hardware fails and the operations team migrates the application to a new server with IP 198.51.100.44, every single user bookmark, mobile app configuration, and external API integration breaks instantly.

The Domain Name System (DNS) is a distributed, hierarchical database that translates human-friendly domain names (such as checkoutlab.com) into computer-routable IP addresses (such as 203.0.113.10) and associated network records.

This lesson answers one central question: How does the Domain Name System hierarchically translate human domain names into IP addresses, how do recursive resolvers and TTL caches accelerate resolution, and how do engineers design DNS for high availability and zero-downtime cutovers?

The Four-Tier DNS Hierarchy

DNS does not rely on a single central database server. Instead, DNS operates as a globally distributed tree structure organized into four distinct server tiers:

flowchart TD
  Client[1. Client Application / Browser] --> Resolver[2. Recursive Resolver<br/>ISP / 8.8.8.8 / 1.1.1.1]
  Resolver -->|Ask: Who owns .com?| Root[3. Root Name Server<br/>. Root Tier]
  Root -->|Returns: .com TLD Server IP| TLD[4. TLD Name Server<br/>.com Server Tier]
  TLD -->|Returns: checkoutlab.com NS IP| Auth[5. Authoritative Name Server<br/>ns1.dns-provider.com]
  Auth -->|Returns: A Record 203.0.113.10| Resolver
  Resolver -->|Returns: 203.0.113.10 + TTL 300s| Client

Figure 1: The hierarchical 4-tier iterative DNS lookup flow.

The Four Server Tiers

1. Recursive Resolver (DNS Recursor): The initial server contacted by the client OS. The resolver executes the heavy lifting of querying the DNS hierarchy on behalf of the client and caching the final answer.
2. Root Name Servers (.): 13 logical root server addresses (operated by ICANN across hundreds of global Anycast locations) that direct queries to Top-Level Domain (TLD) servers.
3. Top-Level Domain (TLD) Name Servers: Servers responsible for specific domain extensions (.com, .net, .org, .io). They direct queries to the authoritative name servers owning the domain.
4. Authoritative Name Servers: The final source of truth. These servers hold the actual DNS record definitions for a specific domain (e.g. checkoutlab.com) configured by the domain owner.

Complete Step-by-Step Resolution Trace

Let's trace what occurs when a user types https://api.checkoutlab.com into a web browser for the first time:

sequenceDiagram
    autonumber
    actor User as User Browser
    participant OS as OS DNS Cache
    participant Res as Recursive Resolver (8.8.8.8)
    participant Root as Root Server (.)
    participant TLD as TLD Server (.com)
    participant Auth as Authoritative Server (NS)
    
    User->>OS: GET api.checkoutlab.com
    Note over OS: Cache Miss!
    OS->>Res: Query A api.checkoutlab.com
    Note over Res: Resolver Cache Miss!
    
    Res->>Root: Query A api.checkoutlab.com
    Root-->>Res: Referral to .com TLD (IP: 192.5.6.30)
    
    Res->>TLD: Query A api.checkoutlab.com
    TLD-->>Res: Referral to Authoritative NS (IP: 205.251.192.2)
    
    Res->>Auth: Query A api.checkoutlab.com
    Auth-->>Res: Answer: A 203.0.113.10 (TTL: 300s)
    
    Res->>OS: Return 203.0.113.10 (TTL: 300s)
    OS->>User: Return 203.0.113.10
    User->>User: Open TCP Socket to 203.0.113.10:443

Figure 2: Sequence diagram showing iterative DNS resolution across all four tiers.

Essential DNS Record Types

DNS stores multiple types of records within a domain's zone file, serving different operational purposes:

Time To Live (TTL) and Cache Expiration Mechanics

Every DNS response includes a Time To Live (TTL) value expressed in seconds. The TTL dictates how long recursive resolvers, operating systems, and browsers may cache the record before issuing a new lookup to the authoritative server.

gantt
    title DNS TTL Cache Expiration and Cutover Timeline (TTL = 300s)
    dateFormat  ss
    axisFormat %S
    section Initial Lookup
    Authoritative Query (A = 203.0.113.10) :done, t1, 00, 01
    section Cached Interval (300 Seconds)
    Resolver & OS Serve 203.0.113.10 from Cache :active, t2, 01, 60
    section Record Updated on Server
    Record Changed to 198.51.100.44 :crit, t3, 30, 31
    Resolvers Continue Serving Stale IP (203.0.113.10) :crit, t4, 31, 60
    section Cache Expired
    TTL Expires; Fresh Query Fetches 198.51.100.44 :done, t5, 60, 61

Figure 3: Timeline illustrating stale cache window duration following a DNS record update.

The TTL Trade-Off Matrix

$$\text{Propagation Delay} \le \text{Configured TTL}$$

Zero-Downtime Migration Blueprint: The TTL Step-Down Pattern

When migrating an application to a new load balancer IP address, executing an immediate IP update with a long TTL causes users to hit the old, decommissioned server for hours.

Engineers prevent migration outages using the TTL Step-Down Pattern:

flowchart TD
  Step1["1. Pre-Migration (Days Before):<br/>Lower TTL from 86,400s (24h) to 60s."] --> Step2["2. Wait Window:<br/>Wait 24 hours to ensure all old 24h caches expire globally."]
  Step2 --> Step3["3. Cutover Moment:<br/>Update A record to New IP (198.51.100.44). Keep Old IP active."]
  Step3 --> Step4["4. Rapid Shift:<br/>Traffic shifts to New IP within 60 seconds globally."]
  Step4 --> Step5["5. Decommission & Restore:<br/>Verify zero traffic on Old IP; decommission Old Server; raise TTL back to 3,600s."]

Figure 4: The 5-step operational workflow for zero-downtime DNS IP migration.

Traffic Steering: GeoDNS and Multi-A Round-Robin

DNS is not merely a static directory; modern Anycast DNS networks actively steer traffic based on client geographic location and server health.

flowchart TB
  subgraph Public Internet Clients
    USClient[User in New York]
    EUClient[User in Frankfurt]
  end
  subgraph GeoDNS Authoritative Server
    GeoDNS{GeoDNS Engine}
  end
  subgraph Regional Origin Load Balancers
    USLB[US-East Load Balancer: 203.0.113.10]
    EULB[EU-West Load Balancer: 198.51.100.20]
  end
  
  USClient -->|Query A api.checkoutlab.com| GeoDNS
  EUClient -->|Query A api.checkoutlab.com| GeoDNS
  GeoDNS -->|Inspect Client IP Subnet| USLB
  GeoDNS -->|Inspect Client IP Subnet| EULB

Figure 5: GeoDNS steering routing users to physically proximate regional load balancers.

1. Multi-A Record Round-Robin

2. GeoDNS (Latency-Based Steering)

3. Health-Checked DNS Failover

Complete Worked Example: CheckoutLab BIND Zone File

Let's inspect the production DNS zone file for the CheckoutLab domain (checkoutlab.com).

Production BIND Zone File Specification

$TTL 300
@   IN  SOA ns1.dns-provider.com. admin.checkoutlab.com. (
            2026072301 ; Serial Number (YYYYMMDDNN)
            7200       ; Refresh (2 hours)
            3600       ; Retry (1 hour)
            1209600    ; Expire (2 weeks)
            300        ; Minimum TTL (5 minutes)
)
; Name Servers
@   IN  NS  ns1.dns-provider.com.
@   IN  NS  ns2.dns-provider.com.
; Apex Domain Records
@   IN  A   203.0.113.10
@   IN  AAAA 2607:f8b0:4005:805::200e
; Service Subdomains
api IN  A   203.0.113.10
api IN  A   203.0.113.11
www IN  CNAME checkoutlab.com.
; Mail Exchanger & Security Auth
@   IN  MX  10 mail.checkoutlab.com.
@   IN  TXT "v=spf1 include:_spf.google.com ~all"

Failure Modes and Engineering Mitigations

What You Should Remember

1. DNS is a 4-tier hierarchy: Resolvers query Root (.), TLD (.com), and Authoritative servers iteratively to resolve domain names to IP addresses.
2. TTL governs cache duration: Resolvers cache responses for TTL seconds. Short TTLs (60s) enable fast failover; long TTLs (24h) reduce lookup overhead.
3. Use the TTL Step-Down Pattern for migrations: Lower TTLs 24 hours prior to IP cutovers to prevent stale cache outages.
4. Distinguish record types: A maps to IPv4, AAAA to IPv6, CNAME aliases names, MX routes mail, and TXT stores security verification metadata.
5. DNS is critical infrastructure: Protect registrar accounts with MFA and consider Dual-Provider DNS to survive vendor outages.

Glossary of Terms

Practice Scenario and Self-Assessment

Architecture Scenario

Current DNS configuration: shop.com IN A 203.0.113.50 with TTL = 86400 (24 hours).

Questions:

1. Formulate a 4-day step-by-step migration schedule to guarantee zero downtime for shopping customers.
2. Explain what happens to users if you change the A record to 198.51.100.99 without lowering the 86,400s TTL in advance.

Interactive Self-Assessment

It allows existing long-cached records to expire globally so resolvers adopt the new IP within seconds of the cutover.

It reduces network bandwidth consumption during the database migration.

It instructs web browsers to close open TCP connection sockets.

It automatically bypasses HTTPS certificate validation for 24 hours.

CNAME Record

A Record

MX Record

TXT Record

What to Learn Next

• HTTP and HTTPS — Protocols, Headers, and Security: Master what occurs after DNS resolves the server IP address.
• TCP vs UDP — Reliable Streams vs Low-Latency Datagrams: Explore transport protocols underlying DNS and HTTP.
• Load Balancing — Algorithms and Layers: Learn how traffic managers distribute requests behind DNS entries.

Track: Engineering Foundations

Next: Gossip Protocol — Epidemic Membership and State Spread

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab