Every system design interview starts with a client making a request. Before that request reaches your load balancer, DNS has already run. DNS translates api.example.com into an IP address. It’s a globally distributed read-heavy system that handles 3.5 trillion queries per day. Understanding how resolution works explains why DNS changes take time to propagate and how DNS-based traffic routing is possible.

The Resolution Chain#

A DNS query for api.example.com follows a chain of four server types:

Recursive resolver: the first stop, usually run by your ISP or a public resolver (8.8.8.8, 1.1.1.1). It does the work of resolving the full name by querying other servers on your behalf.

Root nameservers: 13 logical root server clusters (A through M). They don’t know IP addresses for domain names but know where to find authoritative servers for each TLD.

TLD nameservers: authoritative for .com, .org, .io. Know which nameserver is authoritative for example.com.

Authoritative nameserver: holds the actual DNS records for example.com. Returns the IP for api.example.com.

sequenceDiagram autonumber participant C as Client participant R as Recursive Resolver participant Root as Root Nameserver participant TLD as .com TLD Nameserver participant Auth as Authoritative NS (example.com) C->>R: Resolve api.example.com R->>Root: Who handles .com? Root->>R: TLD NS for .com: 192.5.6.30 R->>TLD: Who handles example.com? TLD->>R: Auth NS: ns1.example.com R->>Auth: What is api.example.com? Auth->>R: A record: 203.0.113.42, TTL 300 R->>C: 203.0.113.42

Caching and TTL#

Each DNS record has a TTL (time-to-live) in seconds. Recursive resolvers cache responses for the duration of the TTL. A record with TTL 300 is cached for 5 minutes; subsequent queries within that window are served from cache without querying the authoritative server.

This is why DNS propagation takes time: when you change an A record, existing cached responses remain valid until their TTL expires. Setting a low TTL (60 seconds) before a planned IP change minimizes propagation delay at the cost of more queries to your authoritative server.

The root and TLD nameservers have very long TTLs (days to weeks) because they change rarely. Authoritative records for services have shorter TTLs (minutes to hours) to allow faster failover.

Negative Caching#

If a domain doesn’t exist, that negative result is also cached. The SOA record’s minimum TTL field controls how long negative responses are cached. Querying a nonexistent subdomain repeatedly still hits the cache after the first query.

At Oracle#

Oracle Cloud’s DNS service handles authoritative DNS for customer domains. During a major cloud region failover drill, we needed all DNS records pointing to the primary region to update to the backup region. Records with TTL 300 took up to 5 minutes to converge globally. Records with TTL 3600 took up to an hour. The lesson: for any service that needs DNS-based failover, set TTL to 60-300 seconds in steady state, not the default 3600. We added a TTL compliance check to our pre-incident runbooks.

What I’m Learning#

DNS resolution is a read-heavy distributed cache with TTL-based expiry. The four-step chain (recursive, root, TLD, authoritative) runs once per TTL period per resolver; everything else hits the cache. TTL is the knob that controls the trade-off between cache efficiency and update propagation speed.

Have you been caught out by long DNS TTLs during an incident, and what TTL policy did you adopt afterward?