DNS

Resolution Flow

When a client looks up api.example.com, it first checks local caches: the browser cache, then the OS resolver cache. On a miss, the query goes to a recursive resolver, typically the ISP's or a public one like Cloudflare 1.1.1.1 or Google 8.8.8.8. The recursive resolver does the real work: it asks a root nameserver (13 logical root server identities, each an anycast cluster of hundreds of machines), which points to the .com TLD servers, which point to example.com's authoritative nameservers (hosted by a provider like Route 53, Cloudflare, or NS1), which finally return the A or AAAA record.

Every hop caches aggressively, so in practice most lookups are answered from cache in single-digit milliseconds and never touch the root or TLD servers. A full cold resolution takes tens to a couple hundred milliseconds, which is why DNS latency matters for first-visit page load and why browsers do DNS prefetching.

Know the distinction between a recursive resolver (does the full walk on behalf of clients, caches results) and an authoritative server (owns the zone and gives definitive answers). Route 53 and Cloudflare DNS are authoritative services; 8.8.8.8 is a recursive service.

Record Types

The records that matter in system design: A maps a name to an IPv4 address, AAAA to IPv6. CNAME aliases one name to another (www.example.com to example.com), with the constraint that a CNAME cannot coexist with other records at the same name, which is why zone apexes need A records or provider-specific ALIAS/ANAME flattening. NS records delegate a zone to authoritative nameservers, MX routes mail, and TXT carries arbitrary text used for domain verification, SPF, DKIM, and DMARC.

SRV records carry port and priority information and appear in service discovery contexts, Consul and Kubernetes expose DNS SRV interfaces. CAA records restrict which certificate authorities may issue certs for a domain, a small but nice security detail to mention.

A practical pattern: point a CNAME at a load balancer or CDN hostname (d123.cloudfront.net) rather than hardcoding IPs, so the provider can change underlying addresses freely.

TTL and Caching Behavior

Every record carries a TTL (time to live) that tells resolvers how long to cache it. Long TTLs (3600 seconds to 24 hours) reduce query load and lookup latency; short TTLs (30-60 seconds) let you change answers quickly for failover or migrations. A common operational play is to lower TTL from 1 hour to 60 seconds a day before a planned migration, cut over, verify, then raise it back.

The catch is that TTLs are advisory. Some resolvers ignore very low TTLs, some applications and JVMs cache DNS results indefinitely unless configured otherwise, and mobile carriers are notorious for stale caches. So DNS failover is best-effort with a tail: after you change a record, most traffic moves within the TTL window, but a residual trickle can hit the old IP for hours. Any design that relies on DNS for failover should keep the old endpoint able to respond or redirect during that tail.

Negative caching also exists: NXDOMAIN responses are cached according to the zone's SOA settings, which can make a freshly created record appear broken for a few minutes if someone queried it before it existed.

DNS Load Balancing, GeoDNS, and Anycast

DNS can return multiple A records (round-robin DNS), and clients pick one, spreading load coarsely across servers. It is crude: no health awareness by default, no load feedback, and cache-skewed distribution. Managed DNS providers improve on this with health-checked records, Route 53 removes an IP from answers when its health check fails, plus routing policies: latency-based (answer with the region closest in measured latency), geolocation (answer based on where the user is, useful for data-residency rules), and weighted (send 10 percent of traffic to a new region).

GeoDNS works by looking at the recursive resolver's IP (or the EDNS Client Subnet extension for better accuracy) to infer user location. This is how a single hostname sends European users to eu-central and US users to us-east, forming the top layer of global load balancing.

Anycast is the complementary technique: advertise one IP from many locations via BGP, and the internet routes each user to the topologically nearest site. All large CDNs and public resolvers run anycast; Cloudflare serves its entire network from a small set of anycast IPs across 300+ cities. Anycast fails over in seconds via BGP reconvergence and needs no cache expiry, which is why it beats DNS-based failover for speed, but it offers less fine-grained control over traffic split percentages.

Tradeoffs