<aside> 🧭

Module 09 · Performance, Reliability & Security at Scale

The last module. How 13 root server names become a thousand machines; what DNS load balancing can and cannot do; TTL strategy for cutovers; amplification, reflection and rate limiting; what the anti-spoofing measures really buy; encrypted DNS; and the incident playbooks that tie all nine modules together.

🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)

Prerequisite: Modules 01–08. This module is mostly a synthesis — it assumes the whole track.

</aside>

Part A · Making DNS fast and available

A1 · Anycast — how 13 names become a thousand servers

<aside> 🏪

The analogy. Think of a shop chain with one national phone number.

You dial it from Penang and the nearest Penang branch picks up. Someone dials the same number in Johor and gets Johor. Nobody was told a different number and nobody chose a branch.

And when a branch closes for the day, calls simply start ringing at the next one — instantly, with no announcement. That is why anycast gives you the fast failover a DNS record change never can: the number never changed, so nobody is holding an old one.

</aside>

<aside> 📖

Official docs: RFC 4786 — Operation of Anycast Services (BCP 126) · RFC 7094 — Architectural Considerations of IP Anycast · IANA Root Servers

</aside>

Module 01 A2 promised an explanation: there are 13 root server identities, and over a thousand physical machines answering on those same 13 addresses. Anycast is the mechanism.

<aside> 🔑

Anycast is not a DNS feature at all — it is BGP. The same IP address is announced from many locations at once, and each router forwards packets toward whichever announcement is closest by its own routing metric. A client in Stockholm and a client in São Paulo send to the identical address and reach different machines.

Three properties follow, and they are exactly what DNS needs:

1. Latency drops, because every user reaches a nearby instance without any per-user decision being made
2. Failure is automatic — an instance that stops announcing the route simply disappears, and traffic re-converges with no DNS change and no TTL to wait out
3. DDoS traffic is divided across every site rather than concentrated on one

And note point 2 carefully, because it is the answer to Module 08 A3's limitation. Anycast provides the fast failover that DNS records cannot: no cache holds a stale answer, because the address never changed.

</aside>

<aside> ⚠️

The trade-off is that routing can change mid-conversation. A BGP re-convergence can move you to a different instance between two packets. For a stateless UDP query that is harmless — which is precisely why DNS is the archetypal anycast service. For a long-lived TCP connection it is a reset, which is why anycast + TCP needs more care, and why it matters that DNSSEC has pushed more DNS onto TCP.

</aside>

🧪 Exercise A1.1 — Prove you are talking to a nearby instance

# the same address, different answer depending on where you are
dig @a.root-servers.net hostname.bind CH TXT +short
dig @k.root-servers.net hostname.bind CH TXT +short

# compare the latency to a root server with a distant unicast host
dig @a.root-servers.net . SOA +noall +stats | grep 'Query time'

• ✅ Expected result — click to reveal

A2 · DNS load balancing, and its real limits

<aside> 🍽️

The analogy. Think of a host at the restaurant door who can send people to a table but cannot see how busy each waiter is.

He alternates politely: table 1, table 2, table 3. Then a coach party of forty arrives, is told "table 4", and all forty go to table 4.

That is DNS load balancing. It shares out the people who ask, not the work — and one resolver serving a million users counts as one person asking.

</aside>

<aside> 📖

Official docs: RFC 1794 — DNS Support for Load Balancing · RFC 2181 §5 — RRsets are unordered · Route 53 weighted records

</aside>

<aside> ⚠️

Four reasons DNS is a poor load balancer, and each one is something you have already seen.

1. It distributes lookups, not requests. One resolver serving a million users caches one answer and sends them all to the same address. Cache hit rate, not user count, decides the split
2. The client chooses. Module 02 A1: an RRset is unordered, and the client picks. getaddrinfo may reorder or prefer IPv6 regardless of what you sent
3. It cannot see load. DNS knows nothing about connections, CPU or queue depth — only whether a health check passed
4. Withdrawal is slow. TTLs, resolver floors, serve-stale and application caches all outlive your decision

So the honest positioning: DNS distributes traffic at the coarse, geographic, slow layer. Real balancing happens at the load balancer or in the client. Saying that in an interview is worth more than listing the policies.

</aside>