DNS Resolution

Also Known As

TL;DR

Explanation

DNS resolution begins at a recursive resolver (usually provided by the ISP or a public resolver like 8.8.8.8). If not cached, the resolver queries root nameservers, then TLD nameservers, then the authoritative nameserver for the domain. Results are cached for the duration specified by the TTL. High TTLs reduce DNS latency but slow propagation of changes; low TTLs enable fast failover but increase resolver load.

Diagram

sequenceDiagram
    participant C as Client
    participant R as Recursive Resolver
    participant ROOT as Root NS
    participant TLD as .com NS
    participant AUTH as example.com NS
    C->>R: Where is example.com?
    R->>ROOT: Where is .com?
    ROOT-->>R: Ask TLD NS
    R->>TLD: Where is example.com?
    TLD-->>R: Ask AUTH NS
    R->>AUTH: What is example.com?
    AUTH-->>R: 93.184.216.34 (TTL 3600)
    R-->>C: 93.184.216.34 (cached)

Common Misconception

Why It Matters

Common Mistakes

• High TTLs before a planned migration — reduce TTL days before to enable fast propagation.
• Not removing CNAME records when deprovisioning cloud resources — enables subdomain takeover.
• Using A records instead of CNAME for load balancers that change IP — the IP becomes stale.
• Forgetting that DNS is the first step in every request — slow DNS adds latency to every connection.

Code Examples

# DNS record not removed after deprovisioning:
; staging.example.com CNAME myapp.herokuapp.com
; Heroku app deleted — CNAME still exists
; Attacker registers same Heroku hostname → subdomain takeover

# DNS best practices:
; Lower TTL before planned changes:
example.com. 300 IN A 203.0.113.1   ; 5min TTL for pre-migration

; Remove records when deprovisioning:
; Run: dig staging.example.com — verify no dangling CNAMEs

; Use ALIAS/CNAME for load balancers that change IP:
www IN CNAME myapp.us-east-1.elb.amazonaws.com.

References

• ↗ https://www.cloudflare.com/learning/dns/what-is-dns/

Tags

Related Terms