DNS Resolution & Traffic Steering

DNS is your first routing and failover lever

DNS is not just a phone book. It is the first routing and failover lever a request touches, and its main limitation, caching you do not control, is the single most misunderstood thing about it.

The resolver chain

Your app calls the OS stub resolver, which asks a recursive resolver (your ISP's, or 8.8.8.8, or 1.1.1.1). If that recursive resolver has no cached answer it walks the hierarchy: a root server returns the nameservers for .com (the TLD), the TLD returns the authoritative nameservers for example.com, and the authoritative server (Route 53, NS1, Cloudflare) returns the actual A record. Caching happens at every hop: the browser caches, the OS caches, the recursive resolver caches, each keyed by TTL. That is the whole point and the whole problem.

Record types you must know: A (name to IPv4), AAAA (name to IPv6), CNAME (alias one name to another, cannot exist at the zone apex or alongside other records), NS (delegation), and provider ALIAS/ANAME records, which behave like a CNAME but are legal at the apex (example.com itself) because the provider resolves them server-side and returns an A record.

Interview nuance: "why can't I CNAME my apex to my load balancer?" is a real, common gotcha. Answer: the apex needs SOA/NS records that a CNAME would forbid coexisting with; use ALIAS/ANAME.

TTL: the core tradeoff

A short TTL (say 60s) means clients re-query often, so a failover or IP change propagates fast, at the cost of far more DNS queries and dependence on your DNS provider's availability. A long TTL (say 3600s) is cheap and resilient but means an IP change takes up to an hour to be seen. The trap: even a 60s TTL does not give instant failover, because misbehaving recursive resolvers and corporate caches ignore or clamp TTLs, and clients that already resolved keep using the stale IP until their cache expires. So DNS failover is best-effort and eventually-consistent, on the order of minutes, not milliseconds.

Steering traffic with DNS

Authoritative providers return different answers based on the querier. GeoDNS returns the IP of the nearest region by the resolver's location. Latency-based routing (Route 53) returns the region with the lowest measured RTT to the user. Weighted routing splits traffic by percentage, which is how you do blue-green and canary at the DNS layer. Crucially, pair these with health checks: the authoritative server stops handing out a region's IP when its health check fails. Without health checks, plain round-robin DNS will keep sending one in N users to a dead box.

The hard limit: DNS load balancing has no per-request awareness. It cannot see server load, cannot do sticky sessions, cannot retry. It steers at the granularity of "which IP do I hand back," resolved once and cached. So DNS gets a user to the right region or the right LB, and a real L4/L7 load balancer takes over from there.

Recap: DNS resolves through a cached recursive-to-authoritative chain, TTL trades failover speed for query load but never gives instant failover because of resolver caching, and GeoDNS/latency/weighted routing plus health checks steer users to the nearest healthy region before a real LB takes over.