DNS in depth

Why it matters

Nearly every network request begins with a DNS lookup, and DNS is one of the few systems whose failure takes everything down at once: when names stop resolving, healthy services become unreachable. DNS is also a traffic-steering tool (failover, geographic routing, blue-green cutovers), and most surprises with those tools come from caching behaving exactly as designed. The System Design track uses DNS for load balancing; this lesson explains the machinery underneath.

The idea

DNS is a distributed, hierarchical, heavily cached database mapping names to records. No server knows everything; each knows its own zone and where to find the next level down. A lookup walks the hierarchy from the root, and caching at every step makes almost all lookups answer from memory.

The cast

A lookup, step by step

The resolver caches each answer, including the referrals, so the next lookup for anything under .com skips the root, and the next lookup for api.example.com returns instantly until its TTL runs out.

Record types you will use

TTLs and caching, honestly

Every record carries a TTL in seconds, and every cache (recursive resolvers, operating systems, language runtimes, browsers) may keep it that long. Consequences: a DNS change takes up to the old TTL to reach everyone, plus whatever caches ignore TTLs; lowering a TTL only helps if done at least one old-TTL ahead of the change; very low TTLs increase query load and make you more dependent on your DNS provider's availability. Failed lookups are cached too: a "no such name" answer is cached for the zone's negative TTL (from its SOA record), so querying a name before you create it can make clients see it as missing for minutes after it exists. Some runtimes cache aggressively by default (older JVMs cached successful lookups forever), which defeats DNS failover.

Transport, security and privacy

DNS normally uses UDP port 53 for small queries and falls back to TCP for large answers. Classic DNS is unauthenticated and unencrypted, which allows spoofing and cache poisoning. DNSSEC signs records so resolvers can verify they came from the zone owner, at the cost of operational care with keys. DNS over HTTPS and over TLS encrypt the client-to-resolver leg for privacy. Inside companies, split-horizon DNS returns internal addresses to internal clients and public ones to everyone else.

How DNS fails

1. 1

   Provider outage

   If your only authoritative provider goes down, cached answers survive only until their TTLs expire, then your names vanish. Use two providers or a provider with a strong availability record, and keep TTLs long enough to ride out short incidents.
2. 2

   Delegation mistakes

   Wrong NS records at the registrar, or a lapsed domain, make the whole zone unreachable, sometimes with days of cached damage.
3. 3

   Resolver overload

   A busy service resolving names on every request can overwhelm a VPC resolver's per-instance query limit; cache in-process and reuse connections.
4. 4

   Routing takes DNS with it

   If your authoritative servers live inside prefixes you accidentally withdraw from BGP, your DNS disappears along with your services, making recovery harder.

Trade-offs

Hierarchy and caching make DNS scale to the whole internet with tiny per-query cost, at the cost of slow, uneven propagation of changes and limited control over what clients have cached. Short TTLs buy agility for failover and cutovers and cost query volume and resilience to provider outages; long TTLs are the reverse. DNSSEC buys integrity at the cost of key management that, done badly, causes outages of its own.

In an interview

Show you know the cache is the hard part: "We run two authoritative providers. Failover records have a 60-second TTL; stable records have an hour. Before a planned cutover we lower the TTL a day ahead. Services cache lookups in-process respecting TTL, and the JVM's DNS cache is configured not to cache forever." That is the difference between using DNS and operating it.