Topic 6.10
DNS Resolution Flow
In one line
The exact path a name takes to become an IP — and the trip points where HLDs get slow or break.
Think of it like this
Looking up a friend's phone number in your phone's saved contacts first, then asking a friend who might know, then calling directory enquiries as a last resort. DNS lookups check several 'phone books' in order, from fastest and closest to slowest and most authoritative.
Key ideas
- 01
Full path: browser cache → OS resolver → recursive resolver (ISP/8.8.8.8) → root → TLD (.com) → authoritative NS → answer.
- 02
Caching happens at every hop (TTL-limited) — that's why DNS changes take minutes to hours.
- 03
Load balancer front: DNS returns the LB VIP (a single IP or a pool), LB distributes to servers.
- 04
Geo-DNS: returns the nearest region's LB → the fastest path for global users.
- 05
Failures: stale DNS after LB swap, TTL too long during failover, resolver timeouts on cold starts.
- 06
The one-line story the syllabus wants: Browser → DNS → Load Balancer → Server → Database.
Java / Spring map
- →
Spring Cloud DiscoveryClient resolves service names to instances — in-cluster DNS for service discovery.
Code & diagrams
Every hop caches the answer for its own TTL — that's why DNS changes take time to fully propagate.
Explain without notes
Why can a fast failover be slowed by a client's aggressive DNS cache? Fixes?
Practice
Trace the flow for 'android app → api.uber.com' with geo-DNS and explain where each cache sits.
Trade-offs
- ↔
Long TTL = fast, but slow failover; short TTL = fast failover, more resolver traffic. 30–60s is a sane cap.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can walk the DNS chain and point at every cache that could serve stale data.