DNS

Routers forward packets by IP address, not names — the name is a human convenience the network layer can't use. So the OS must first map name → IP. The chain: browser → OS stub resolver → recursive resolver (your ISP / 8.8.8.8) → root server → TLD server (.com) → authoritative server.

• Cause: only the authoritative server knows the real answer for example.com.
• Effect: the recursive resolver walks the hierarchy: root tells it which .com TLD server to ask, the TLD points to the authoritative nameserver, the authoritative returns the A record.

Trade-off / cost: a fully cold lookup is up to 4 sequential round trips (stub→recursive, then recursive→root, →TLD, →authoritative). Over the open internet that can be 50–200 ms before the first byte of your real request — pure overhead. That cost is exactly why every layer caches (next step).

Every record carries a TTL (time-to-live, in seconds). Any resolver may cache the answer until the TTL expires. Caches stack: browser cache → OS cache → recursive resolver cache.

• Cause: the recursive resolver caches the A record with TTL=300s.
• Effect: for the next 5 minutes, lookups for that name skip root/TLD/authoritative entirely — answer served from local memory in <1 ms instead of ~100 ms. With millions of users behind one resolver, the authoritative server sees a tiny fraction of total query volume.

Trade-off / cost: the answer is now stale by up to TTL seconds. If you change the IP, old clients keep hitting the old IP until their cached copy expires. TTL is the dial between cheap/fast (high TTL) and agile/controllable (low TTL) — you can't max both.

Lower the TTL well before the change, then raise it back after.

• Cause: at least 24h before (so the old day-long cached entries have time to expire), set TTL to 60s.
• Effect: once those old 24h-cached entries naturally expire, every resolver is re-fetching every 60s. On cutover, clients converge on the new IP within ~60s instead of up to 24h.
• After it's stable, raise TTL back to e.g. 3600s to cut query load and latency again.

Trade-off / cost: a 60s TTL means resolvers re-query ~1440×/day instead of once — more load on authoritative servers and slightly higher average lookup latency for users. Low TTL buys failover agility at the price of query volume; that's why you don't just leave it at 60s forever. (Caveat: many resolvers clamp very low TTLs to a floor of ~30–60s, so don't assume a 1s TTL is honored.)

Use round-robin DNS: publish multiple A records for the same name.

• Cause: web.example.com → [10.0.0.1, 10.0.0.2, 10.0.0.3], and the authoritative server rotates the order it returns them on each query.
• Effect: different clients get a different IP first, so over ~1000 clients each server receives roughly 1/3 of new resolutions — crude traffic spreading for free, with no extra network hop.

Trade-off / cost: it's blind. DNS doesn't know server load or even whether a server is up. Caching means a heavy client can pin to one IP for the whole TTL, so distribution is uneven. And clients typically connect to the first IP returned (only falling back to the rest if it's unreachable). It balances resolutions, not requests — fine for coarse spreading, not for true load balancing.

Use a managed DNS provider with health checks (e.g. Route 53, NS1). The provider actively probes each endpoint and only returns healthy IPs.

• Cause: the health checker probes 10.0.0.2 every 30s; after N consecutive failures it marks the IP unhealthy.
• Effect: that IP is removed from DNS answers, so new resolutions only return live servers — automatic failover with no human in the loop.

Trade-off / cost: failover is not instant — it's gated by detection time + TTL. With a 30s health interval and a 60s TTL, some clients can keep hitting the dead IP for up to ~90s because of cached answers. This is the core limitation of DNS failover: you can't force-expire a cache you don't control, so DNS failover is a coarse, tens-of-seconds-to-minutes safety net, not millisecond HA.

Use geo / latency-based routing at the authoritative DNS layer — the same name resolves to different answers depending on who's asking.

• Cause: the authoritative server inspects the resolver's source IP (or EDNS Client Subnet) to estimate location.
• Effect: Berlin user → Frankfurt IP, New York user → Virginia IP. Avoiding a cross-Atlantic round trip cuts each leg of connection setup from ~85 ms to ~10 ms — so a TLS handshake that took well over 150 ms now finishes in tens of ms, and EU data stays in-region for compliance.

Trade-off / cost: accuracy depends on the resolver's location, not the user's — someone in Berlin using a US-based public resolver may get routed to Virginia. EDNS Client Subnet helps but isn't universal, and per-region answers make caching and debugging harder because the "correct" answer is now relative to who asks.

Run multiple authoritative nameservers, ideally across independent providers, advertised via several NS records for the zone.

• Cause: you publish ns1…ns4 on independent infrastructure, often using Anycast so one IP is announced from many global locations.
• Effect: if one nameserver or region fails, resolvers retry the next NS; Anycast also routes each query to the nearest live node, so a regional outage just shifts traffic instead of breaking resolution.

Trade-off / cost: multi-provider DNS adds operational complexity — you must keep zone records in sync across providers, and a misconfiguration now exists in two places. It's insurance you pay for in config overhead, justified because DNS is the front door: if it's down, 100% of traffic is down regardless of backend health. (Note: the well-known "13" is the number of root-server identities — a limit driven by fitting the list in a UDP DNS response, not a protocol cap on how many nameservers your own zone may have.)

DNS is the wrong tool for fine-grained or fast control because of the cache you don't own.

• Cause: once a resolver caches an answer, you cannot revoke it before its TTL; clients also tend to use just the first returned IP.
• Effect: DNS gives you coarse, region-level steering and tens-of-seconds-to-minutes failover, but it can't do per-request balancing, session stickiness, connection draining, or sub-second failover.

Trade-off / cost: the standard pattern is layered: DNS routes the user to the nearest region (cheap, global), then a real load balancer inside that region does per-request distribution and instant health-based failover. Use DNS for the coarse first hop; use an LB for everything that must react in milliseconds. Saying this out loud signals you know DNS's limits, not just its features.