Domain name system (DNS)

Why it matters

Every connection starts with a name lookup. DNS is what lets you replace a server, move to a new region or fail over to a standby without clients noticing, and its time-to-live values decide how long "without noticing" takes. It is also involved in a disproportionate share of outages, usually because a change was made with a long TTL still cached around the world, or because the one DNS provider was down. Treating it as infrastructure rather than configuration is a mark of maturity.

The idea

DNS is a distributed, hierarchical database that maps names to records, mostly addresses. Resolution walks from the root down through delegations, caching at every step.

Record types that appear in designs

Record	Maps	Use
A / AAAA	name → IPv4 / IPv6 address	The load balancer's addresses
CNAME	name → another name	Point www at the apex, or your name at a CDN's name
ALIAS / ANAME	apex name → another name (provider-specific)	CNAME-like behaviour at the zone apex, where CNAME is not allowed
MX	domain → mail servers	Email delivery
TXT	name → text	Domain verification, SPF, ACME challenges for certificates
NS	zone → authoritative servers	Delegation; changing providers
SRV	service → host and port	Service discovery in some internal systems

TTL: the dial that controls every change

Each record carries a TTL in seconds; resolvers cache it for that long. A TTL of 3,600 means a failover or migration can take up to an hour to reach everyone, and some resolvers ignore TTLs and cache longer. The operational pattern: lower the TTL to 60 seconds a day before a planned change, make the change, then raise it again once traffic has moved. Keep failover-critical records at a short TTL permanently (30 to 60 seconds); keep stable records longer to reduce lookup latency and resolver load.

DNS as a routing layer

Because the authoritative server chooses what to answer, DNS can route: return the address of the nearest region based on the resolver's location (GeoDNS), return only healthy endpoints (health-checked records), or spread clients across several addresses (round robin). These are coarse tools, bounded by TTL and by clients that cache addresses themselves, which is why they complement rather than replace load balancers. Load balancing with DNS gets its own lesson in the next module.

Where it fails

A single DNS provider is a single point of failure for everything with your name on it; large providers have had multi-hour outages. Use two providers with the zone synchronised, or at minimum a provider with a strong record and alerting. The other classic failure is a name that resolves to an address that no longer exists because somebody changed infrastructure without changing DNS; automate the record alongside the resource.

Trade-offs

Short TTLs make changes fast and raise lookup volume and latency slightly; long TTLs do the reverse and turn every migration into a planned event. DNS-based routing is cheap and global but imprecise and slow to react. Two providers double the resilience and the operational surface. None of these are hard choices once the numbers are stated; the failure mode is not thinking about them at all.

In an interview

Make DNS visible once: "Clients resolve api.example.com, which has a 60-second TTL and points at the load balancer in the nearest region via GeoDNS; the zone is served by two providers." If regional failover comes up, say the TTL out loud and that failover takes about that long for clients to follow; it shows you know the limit of the mechanism.