DNS Resolution: Path, TTL, Caching & Frontend Impact
Learn the interview-ready mental model, practical trade-offs, and production patterns for this web fundamentals topic.
Topic content
DNS is a layered, distributed caching system. A lookup traverses client → OS → recursive resolver → authoritative nameserver. TTL determines how long responses are cached. Understanding resolution path, caching behavior, and TTL trade-offs is essential for frontend performance, migrations, and incident recovery.
Your browser asks the local post office (OS cache). If not known, it asks the regional hub (recursive resolver). The hub walks up the hierarchy (root → TLD → authoritative) and brings back the address. Once delivered, everyone along the route keeps a copy for the TTL duration. Changing an address doesn't instantly update every post office — old copies must expire.
1DNS Resolution Path
Client → OS cache → Recursive resolver → Root → TLD → Authoritative nameserver. Most lookups are served from cache after the first resolution.
Browser → OS → Recursive Resolver → Root → TLD → Authoritative
2Key Record Types
A/AAAA for IP addresses, CNAME for aliases (common with CDNs), TXT for verification. CNAME chains add extra lookups.
3TTL Strategy
Short TTL (30-300s) = fast failover/migrations. Long TTL (1h–24h) = better cache hit rate and lower load. Lower TTL before big changes.
4Caching Layers & Negative Caching
Browser, OS, Recursive Resolver, ISP/CDN layers. Negative caching (NXDOMAIN) can delay new record visibility.
- ✓DNS is a multi-layer distributed cache, not a real-time lookup
- ✓TTL balances propagation speed vs cache efficiency
- ✓Lower TTL hours before migrations or failovers
- ✓Negative caching can delay visibility of new records
- ✓DNS impacts cold-start TTFB and CDN performance
- ✓Always validate changes with real-user metrics and multiple resolvers