DNS

What is it: Domain Name System translates hostnames to IP addresses. The internet's distributed phone book.

Resolution chain (cache miss):

sequenceDiagram participant Browser participant Resolver as Recursive Resolver participant Root as Root Nameserver participant TLD as TLD Nameserver (.com) participant Auth as Authoritative Nameserver Browser->>Resolver: resolve api.example.com? Resolver->>Root: who handles .com? Root->>Resolver: ask the .com TLD server Resolver->>TLD: who handles example.com? TLD->>Resolver: ask example.com's nameserver Resolver->>Auth: what is api.example.com? Auth->>Resolver: A record: 203.0.113.5 Resolver->>Browser: 203.0.113.5 (cached for TTL)

Browser cache → OS cache + /etc/hosts → recursive resolver (8.8.8.8) → root nameserver → TLD nameserver (.com) → authoritative nameserver → returns A/AAAA record.

TTL: how long caches hold the record. Short TTL: fast failover (IP change propagates quickly), more DNS queries. Long TTL: lower latency (fewer lookups), slower propagation of IP changes. Typical: 300–3600 seconds.

Record types: A (IPv4), AAAA (IPv6), CNAME (alias, not at zone apex), MX (mail), TXT (SPF/DKIM), NS (nameserver), SRV (service discovery with port and priority).

DNS and microservices: Kubernetes services get DNS entries. gRPC clients use dns:///svc:port to get all pod IPs and distribute RPCs client-side.

Worked example — a migration that goes wrong because of TTL: api.example.com has an A record with TTL 3600 (1 hour), pointing at server A. A migration cuts over DNS to point at server B, then shuts server A down 5 minutes later. Every resolver that cached the old record in the preceding hour — ISP resolvers, corporate DNS, even some OS-level caches that ignore TTL under load — keeps returning server A's IP for up to an hour after the cutover. Those clients get connection-refused errors the moment A is shut down, even though the DNS record was "already updated." The fix is to lower the TTL to something small (e.g. 60 seconds) well before the migration window — ideally a day ahead, so the low TTL itself has time to propagate — do the cutover, confirm traffic has shifted, then raise the TTL back up once A is decommissioned and the risk window has passed.