DNS as a Distributed System
Why this matters: DNS is the largest, oldest, and most successful distributed system in production. Every trade-off from the Foundations module is visible in it — and it chose availability over consistency decades before anyone wrote down the CAP theorem.
Key takeaway
DNS is a distributed system that provides resilience (no single point of failure), low latency (responses from geographically nearby servers), and flexibility (traffic can be rerouted during maintenance or failures, ensuring high availability).
Highly scalable
The hierarchical structure is what makes DNS scale. There are 13 logical root name servers, labeled A through M, implemented by many physical instances globally and managed by 12 different organizations. Roughly 1,000 replicated instances of those 13 roots are strategically distributed to handle global traffic.
The workload is divided by tier:
| Tier | Job | Why this divides the load |
|---|---|---|
| Root servers | Direct traffic to the right TLD | Tiny dataset, cached aggressively, rarely reached |
| TLD servers | Filter by domain type | Each handles only its own suffix |
| Authoritative servers | Manage specific records | Each organization serves only its own zone |
This division of labor lets the system manage immense traffic volumes without any tier being overwhelmed.
Reliable
Three factors contribute to DNS reliability:
1. Caching. Browsers, operating systems, and ISP resolvers maintain caches of frequently visited sites. If a DNS server goes down, cached records can still resolve queries — so a failure upstream is invisible to anyone with a warm cache. Caching is not just a performance optimization here; it is a genuine availability mechanism.
2. Server replication. DNS servers are replicated globally. This redundancy ensures that if one instance fails, others handle the load.
3. Protocol. DNS primarily uses UDP. UDP is connectionless and fast, avoiding the latency of TCP's three-way handshake. If a query fails, the client simply retransmits — often to a different server — which delivers resilience without any connection state to recover.
Consistent — deliberately, weakly
DNS prioritizes high performance over strong consistency. It employs eventual consistency: updates to records propagate lazily across the hierarchy, taking anywhere from a few seconds to several days depending on the infrastructure and the specific record.
Caching compounds this. If an organization updates a record on its authoritative server, other resolvers may still serve the old, cached version. To manage that, every record carries a TTL dictating when the cache must expire and refresh.
Two users, same domain, same instant
A natural question: if two users look up the same domain at exactly the same time, how does DNS ensure both reach the correct server?
They may well take entirely different paths — different resolvers, different cache states, different root and TLD instances via anycast — and still arrive at a correct answer, because:
- The authoritative server is the single source of truth for that zone. Every path eventually terminates there.
- Cached copies descend from that same authority, so they are correct as of when they were fetched, and bounded in staleness by TTL.
- Records are effectively immutable within their TTL window. Both users get an answer that was valid when cached.
- If the record changed moments ago, one user may get the old address and the other the new one — and that is acceptable by design, which is exactly why the migration playbook from the previous lesson dual-runs both addresses.
Key takeaway
DNS achieves scale through hierarchy and anycast, reliability through caching, replication, and stateless UDP retries, and availability by explicitly accepting eventual consistency. It is worth studying as a design precisely because every one of those choices is legible.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "DNS is distributed and replicated, so it doesn't have a single point of failure." |
| L5 | Names the mechanisms: "caching, global replication, and UDP with retransmit — and it's eventually consistent, which is what TTL manages." |
| Staff+ | Explains the trade deliberately: "DNS is the canonical AP system — a stale IP is nearly harmless, an unresolvable name is catastrophic. The 13 roots are anycast addresses, not machines, which gives scale, proximity, and failover from one mechanism. And UDP works because a lookup is idempotent, so retrying elsewhere is free." |
Next: using DNS as an active part of your architecture, not just a lookup.