DNS as a Distributed System

In one line: 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.

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.

How 13 becomes 1,000: anycast

The obvious question is how there can be exactly 13 root servers when the internet is global. The answer is anycast: many physical machines share the same IP address, and internet routing delivers each packet to the topologically nearest instance.

So "13 root servers" means 13 addresses, not 13 machines. A query to the K-root from Tokyo and one from São Paulo hit the same IP and land on completely different hardware. This is what simultaneously delivers scalability (add instances without changing anything), low latency (nearby by construction), and resilience (a dead instance is routed around automatically).

Naming anycast here is one of the highest-value details in this chapter — it explains all three properties at once.

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.

Why retransmit-to-a-different-server is elegant

Because UDP is connectionless, a failed query has no state to clean up — the client just asks someone else. Compare that to a TCP-based design, where a dead server means a hung connection, a timeout, and a teardown before you can retry.

This is that building block's failure-model reasoning in practice: DNS treats a lost query as indistinguishable from a slow one and responds by simply asking again elsewhere. The idempotency of a read makes that safe, which is precisely why retry-without-coordination works here and would not for a write.

Secure — the property DNS was not designed with

Scalability, reliability, and weak consistency were all designed in. Security was not, and the gap is worth understanding because it explains three separate pieces of modern infrastructure.

The original protocol has no authentication. A resolver sends a query over UDP and accepts the first plausible-looking answer that comes back.

That is cache poisoning, and the caching that makes DNS fast is what makes it damaging: one accepted forgery is served to everyone behind that resolver for the whole TTL. The attacker does not need to win every race, only one.

Three defences, and the useful thing is that they solve different problems and are not substitutes:

	What it provides	What it does NOT provide
DNSSEC	Authenticity and integrity — records are cryptographically signed, and a resolver can verify a chain of trust from the root down to the zone	Confidentiality. Queries and answers are still plaintext on the wire; anyone on the path sees which domains you looked up
DNS over HTTPS / TLS	Confidentiality — the query is encrypted between the client and its resolver, so the network cannot see or tamper with it	Authenticity of the data itself. A malicious or compromised resolver can still return whatever it likes, encrypted
Source-port and query-ID randomisation	Makes the forgery race far harder to win by widening the space an attacker must guess	A guarantee. It raises the cost rather than closing the hole

The clean way to hold it: DNSSEC secures the answer; DoH and DoT secure the channel. You need both to have neither read nor forged, and an encrypted query to an untrustworthy resolver is still an untrustworthy answer.

DNS as a weapon

The other half of DNS security is not about protecting DNS — it is that DNS is used to attack other people.

Two properties combine into this. DNS runs over UDP, which has no handshake, so the source address is trivially forged. And a small query can produce a large answer, so the attacker's bandwidth is multiplied on the way to the victim.

The mitigations are mostly about not being the amplifier: do not run an open resolver that answers queries from anywhere, apply response rate limiting on authoritative servers so repeated identical queries from one source are throttled, and support the network-level fix of source-address validation so forged packets are dropped near their origin.

The generalizable point is worth taking beyond DNS: any UDP service that returns more bytes than it receives is an amplifier, and the design question is not only "can this be attacked" but "can this be used to attack someone else."

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.

This is the CAP decision, made explicitly

DNS is the canonical AP system from the Foundations module. During a partition — or simply while an update propagates — it keeps answering with possibly-stale data rather than refusing to answer.

That is unambiguously the right call. A stale IP usually still works, because infrastructure changes slowly. An unavailable DNS means the entire internet stops resolving names. Choosing consistency here would trade a minor, self-healing staleness problem for a catastrophic availability one.

This is why "what is the cost of a stale read here?" is the question that decides consistency models — and DNS is the clearest example of the answer being "much lower than the cost of no read at all."

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. Security was not designed in: unauthenticated UDP replies make cache poisoning possible, and one accepted forgery is served to everyone behind that resolver for the whole TTL. DNSSEC secures the answer; DoH and DoT secure the channel — they are not substitutes. And DNS is itself an amplification weapon, because a small spoofed query returns a large reply to a victim who never asked.

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.