DNS Internals, Anycast, and Global Traffic Routing

Before your request reaches a load balancer, a cache, or a single line of your code, something has already decided which continent will answer it.

Most engineers have never looked at what.

Part 4 opened the series' request journey with a promise it deliberately underexplained: "DNS turns the name into an address." One sentence, then we moved on to CDNs and servers.

Sixteen articles later, that sentence has quietly become load-bearing. Bonus E routed requests to instances but waved at the tier above it — "DNS picks the region." Blog 13's redirect and Blog 16's global feed both assumed users somehow reach the nearest infrastructure. Part 17, next, will stream video to a planet, and cannot, until we answer the question every one of those articles postponed: how does a user in Mumbai and a user in Toronto type the same domain and reach entirely different machines, each one close to them, each one healthy?

This is the last unwritten bonus. Time to look under Part 4's one sentence.

The Simple Mental Model: The Global Directory Enquiry

Imagine a worldwide directory service for phone numbers, with one twist: the number you're given depends on where you're calling from, and which offices are currently open.

You ask for "PizzaCorp." Someone in Mumbai is told to call the Mumbai branch; someone in Toronto, the Toronto branch. If the Mumbai branch closes, the directory quietly starts handing out a backup number instead, and callers never know the switch happened.

That is DNS with global routing. The domain name is "PizzaCorp." The directory is the DNS system. The location-aware, health-aware answer is the entire subject of this article.

Four ideas fall out of the metaphor before we touch a single record: a name is not an address, it's a question answered fresh each time. The answer can depend on the asker's location. The answer can change based on health. And crucially, the directory remembers its last answer for a while, which is both a feature and a trap (hold that; it's called TTL).

What DNS Actually Is

DNS — the Domain Name System — is the internet's distributed lookup layer: it translates human names (example.com) into machine addresses (IP addresses) that packets can actually be routed to.

Two framings worth holding together. It's a phone book — name in, number out; the beginner's model, and not wrong. And it's a globally distributed, hierarchical, cached database — that's the system-design model, because every word in that phrase is a design decision this article unpacks.

The scale is staggering and invisible: essentially every internet action begins with a DNS lookup, billions of times per second, and it works so reliably that most engineers never think about it, until a TTL is set wrong, or a resolver caches a dead address, and suddenly "the site is down" for reasons no application log will ever show.

That invisibility is exactly why it deserves an article. DNS failures don't look like DNS failures. They look like outages with no cause — in your logs, because the failure happened one layer before your system was ever reached.

How DNS Resolution Actually Works

When a name must become an address, a small relay race runs — usually in tens of milliseconds, usually cached away to near-zero. The runners: the stub resolver (on your device, the humble starter that just wants an answer), the recursive resolver (your ISP's or a public resolver's workhorse; it does the actual legwork and, critically, caches results), root nameservers (the top of the hierarchy — they don't know example.com, but they know who handles .com), TLD nameservers (the .com, .org, .in… servers — they know who's authoritative for example.com), and authoritative nameservers (the final word — they hold the actual records for the domain).

The race, once (cold cache):

Device → Recursive resolver: "address for example.com?"
   Resolver → Root:        "who handles .com?"        → "ask the .com TLD"
   Resolver → .com TLD:    "who handles example.com?" → "ask example's authoritative NS"
   Resolver → Authoritative: "address for example.com?" → "203.0.113.10"
Resolver → Device: "203.0.113.10"   (and remembers it — see TTL)

The point that matters for design: this only runs in full on a cache miss. The very next lookup for example.com, from anyone using that resolver, is answered instantly from the resolver's cache, until the record's TTL expires. DNS is Part 6's caching lesson, operating as planetary infrastructure: the hierarchy makes it correct; the caching makes it fast.

TTL: The Most Important Number in DNS

Every DNS record carries a TTL — Time To Live: how long resolvers are allowed to cache this answer before asking again.

And here is the trade-off the entire series has trained you to see (Part 6's freshness dial, Bonus F's ELC, now at global scale):

The uncomfortable truths teams learn the hard way. TTL is a promise about the past, not a command about the future. You can lower a TTL, but resolvers that already cached the old record honor the old TTL until it expires. Which means the time to plan a migration is before you need it: drop TTLs to seconds days ahead, let the long-cached copies age out, then make the change.

Some resolvers ignore your TTL. They cache longer than you asked, out of your control. So DNS failover is never instant and never fully reliable as your only recovery mechanism — a lesson that becomes the case for Anycast later in this very article.

DNS TTL is the dial between agility and efficiency, and like every dial in this series, there is no free setting.

DNS Record Types That Matter for Architecture

Not a zone-file tutorial — just the records a system designer actually reasons about: A / AAAA (name → IPv4 / IPv6 address, the fundamental mapping), CNAME (name → another name, an alias — how you point www.example.com at a CDN's hostname without hardcoding its IPs; the CDN changes machines behind its name, you never notice), NS (delegates a domain to its authoritative nameservers — the "ask them instead" pointers from the resolution race), MX (mail routing, out of scope here, but the same lookup machinery), and TXT (arbitrary text, the workhorse of domain verification and email-security records).

The one architectural theme: CNAMEs and the name hierarchy are what let the address behind a name change freely. You publish a stable name; the infrastructure behind it — CDN edges, load balancer IPs, failover targets — shifts constantly underneath. That indirection is the same principle as Part 8's object keys and Part 10's API versioning: a stable public identifier hiding a moving implementation.

Routing Users to the Right Place: GeoDNS and Latency-Based Routing

So far DNS gives one answer per name. Global systems need the answer to depend on who's asking. Authoritative nameservers can do exactly that, returning different addresses based on the query's origin: GeoDNS (answer based on the resolver's geographic location — Mumbai users get the Mumbai IP, Toronto users get Toronto), latency-based routing (answer based on measured network latency, not just geography — the nearest by miles isn't always nearest by network), weighted routing (split traffic by proportion, 90% to the new stack, 10% to the old — DNS as a gradual-rollout tool, Part 9's canary, one layer up), and failover routing (health-checked answers — return the primary while it's healthy, switch to the backup when it isn't).

This is Bonus E's load balancing, lifted to the planetary tier. Bonus E picked an instance within a datacenter; GeoDNS picks the datacenter — the same job (route to the best healthy target), a different altitude. Two officers, two junctions, as Bonus E put it.

But GeoDNS has a structural flaw hiding in plain sight, and fixing it is where Anycast enters.

The Blind Spot

GeoDNS routes on the resolver's location, not the user's. Usually they're close. But a user in one country configured to use a distant public resolver can be routed to the wrong region entirely — the directory answers based on where the operator called from, not the caller.

(There's a mechanism — EDNS Client Subnet — that passes a slice of the user's address to the authoritative server so it can decide by the user's location rather than the resolver's. Useful to know the problem has a partial fix; the deeper answer is architectural, and it's next.)

Anycast: One IP Address, Many Locations

Here is the idea that makes global routing genuinely elegant, and it works at a different layer than everything above.

Everything so far routed by handing out different IP addresses to different users. Anycast does the opposite: it announces the same IP address from many locations at once, and lets the internet's own routing deliver each user to the nearest one.

GeoDNS approach:
  Mumbai user  → DNS returns 203.0.113.10  (Mumbai IP)
  Toronto user → DNS returns 198.51.100.20 (Toronto IP)
  → different ADDRESSES per user

Anycast approach:
  Everyone      → DNS returns 192.0.2.1     (the SAME IP)
  → but 192.0.2.1 is announced from Mumbai, Toronto, London, Tokyo…
  → the network routes each user to the CLOSEST announcement

How? Through BGP, the protocol that decides how traffic flows between networks. Many locations advertise "I am 192.0.2.1"; each network naturally routes toward the closest advertiser. The user's packets go to the nearest edge without DNS choosing per-user, without any per-user decision at all.

Why this is powerful: automatic proximity (no GeoDNS guessing, the network's own path selection finds the nearest edge), automatic failover (if a location stops announcing, because it died, BGP re-routes to the next-nearest, in seconds, with no DNS change and no TTL to wait out — this is the direct fix for DNS failover's slowness), DDoS absorption (a flood aimed at one Anycast IP is spread across every location announcing it, instead of concentrating on one machine — the attack surface disperses itself), and simplicity for clients (one address, everywhere, forever).

The trade-offs (Bonus C — nothing is free): it needs BGP and network infrastructure — Anycast is operated by CDNs, large DNS providers, and big platforms; it's a muscles capability most teams rent rather than build. Long-lived connections can be disrupted if routing shifts mid-session (great for DNS and short HTTP, needs care for stateful streams). And you don't control the routing — BGP decides, you influence, you don't command.

GeoDNS vs Anycast, settled: GeoDNS answers differently per user (application-layer choice, TTL-bound, resolver-location-based). Anycast answers identically and lets the network route (routing-layer, near-instant failover, true-proximity). Real global systems use both — GeoDNS for coarse regional steering and traffic management, Anycast for the DNS servers themselves and for edge proximity. Layers, not rivals — the series' recurring truth.

Bringing It Together: How a Global Request Really Starts

Now Part 4's single sentence, fully unfolded — the journey before the journey:

User in Mumbai types example.com
        ↓
1. Device asks its recursive resolver
        ↓
2. Resolver's own lookups travel to DNS servers reached via ANYCAST
   → hits the nearest DNS infrastructure automatically
        ↓
3. Authoritative server applies GEODNS / latency routing
   → returns the address best for a Mumbai user
   → (or a CNAME to the CDN, which runs its OWN Anycast + GeoDNS)
        ↓
4. Answer cached at the resolver for its TTL
   → the next Mumbai user skips steps 2–3 entirely
        ↓
5. NOW Part 4's journey begins: request travels to the nearest edge,
   through the CDN (Parts 4, 6), to a load balancer (Bonus E),
   to a stateless instance (Part 9)…

Everything the series has taught starts at step 5. This article is steps 1–4, the hidden prologue that decides which copy of your entire system the user was ever going to reach. Blog 16's global feed, Part 17's video, Blog 13's redirect: all of them silently depend on this prologue placing the user at the right edge.

Failure and Operational Realities

DNS's failures are uniquely nasty precisely because they precede your observability (Part 12 can't see what never reached you).

The high-TTL migration trap. You change a record; a chunk of the world keeps hitting the old address for hours because resolvers cached the old TTL. The fix is procedural, not technical: lower TTLs days before a planned change.

Health-check-less failover. Failover routing only works if the DNS provider health-checks the targets. Without it, DNS cheerfully hands out the address of a dead server — a green directory pointing at a closed office.

Resolvers that lie about TTL. Some cache longer than asked. Your "5-minute failover" is 30 minutes for part of the internet. Plan for it; never promise instant DNS failover.

DNS as a single point of failure. If your authoritative nameservers go down, your domain becomes unreachable even though every server is healthy — the most bitter outage there is. The mitigation is redundancy: multiple nameservers, multiple providers, Anycast-backed DNS.

DNS-layer DDoS. Attackers target DNS precisely because it's the front-of-front door. Anycast absorption plus provider-grade protection is the defense.

Observability blind spot. Monitor from outside — synthetic resolution checks from multiple regions (Part 12's black-box monitoring, aimed at DNS). Because when DNS breaks, your internal dashboards stay green while users see nothing.

And the operational north star: health checks make routing honest. GeoDNS, failover, and Anycast are only as good as their knowledge of what's actually alive — the same lesson Bonus E taught for instances, now for whole regions.

Common Mistakes Engineers Make with DNS and Global Routing

Treating DNS as static config — it's a live, cached, routing-capable system, not a set-and-forget text file. High TTLs on records you'll need to change fast — the failover you can't perform for six hours. Lowering TTL at change time, not before — the old TTL still governs the already-cached copies, you're too late. Failover routing without health checks — confidently routing to the dead. Assuming DNS failover is instant — resolver caching and TTL-ignoring make it best-effort, always. No nameserver redundancy — one DNS provider outage equals total domain outage, every healthy server unreachable. Confusing GeoDNS and Anycast — different layers (application vs. routing), different failover speeds, using the wrong mental model debugs the wrong thing. Routing on resolver location and forgetting the user/resolver gap — the distant-public-resolver blind spot, unaccounted for. No external DNS monitoring — the outage your internal observability structurally cannot see. Ignoring DNS as an attack surface — the front door of the front door, left unguarded.

From My Journey: An Architectural Lesson

For a long time, many engineers — myself early on included — treat DNS as a solved checkbox. You buy a domain, point a record at a server, and never think about it again. It sits in a corner of the architecture diagram as a thin arrow labeled "DNS," if it appears at all.

Then something teaches the lesson the hard way. A deployment where traffic keeps flowing to the old servers long after the switch, because a TTL was set to a day. A failover that didn't fail over, because nothing was health-checking the target. An outage where every server was green and users still couldn't connect, because the problem lived one layer before any server.

The realisation that reframes it: DNS is not configuration. It is the first routing decision in the entire system, and it happens before your load balancers, your caches, your code, and your monitoring can influence anything. It decides which copy of your system a user reaches, how fast they get there, and what happens when a whole region falls over.

And it carries the same trade-offs as everything else in this series, just relocated to the top of the stack. TTL is Part 6's freshness dial. GeoDNS is Bonus E's routing, one altitude up. Anycast is failover physics the application layer can't match. None of it is free; all of it is a choice.

The lesson that stuck: DNS is not the address of your system. It is the first decision about where your system even is.

Key Takeaways

• DNS is a globally distributed, hierarchical, cached database — not a static phone book — and it runs before your system is ever reached.
• Resolution is a relay: stub → recursive resolver → root → TLD → authoritative — run in full only on a cache miss, then cached by TTL.
• TTL is the agility-vs-efficiency dial: low means fast failover and more load; high means efficiency and stale answers that linger.
• TTL is a promise about the past — lower it before a migration, because already-cached records honor the old value.
• GeoDNS and latency routing hand out different addresses per user — Bonus E's load balancing lifted to the planetary tier.
• Anycast announces one IP from many locations and lets BGP route each user to the nearest — automatic proximity, near-instant failover, DDoS absorption.
• GeoDNS (application-layer, TTL-bound) and Anycast (routing-layer, instant) are layers, not rivals — real global systems use both.
• DNS failures precede your observability: green dashboards, unreachable site — monitor resolution from outside (Part 12's black-box).
• Health checks make global routing honest; nameserver redundancy prevents the cruelest outage — every server healthy, domain unreachable.

Interview Lens

DNS rarely gets its own interview question, which is exactly why raising it unprompted signals depth. It hides inside "design a global service" and "how do users reach the nearest region?"

The weak answer: "DNS resolves the domain to an IP." The strong answer unfolds the layers: "GeoDNS or latency-based routing steers users to the nearest region, health-checked so a dead region drops out. The DNS servers themselves run on Anycast for proximity and DDoS resilience, and I'd keep TTLs low enough for reasonable failover, knowing resolver caching makes DNS failover best-effort, so Anycast handles the fast failover DNS can't."

Expect the probes: "Why is DNS failover slow?" — TTL caching plus resolvers that ignore TTL; the honest "best-effort, not instant" answer wins. "GeoDNS vs Anycast?" — different layers: per-user addresses vs. one address routed by the network; failover speed is the tell. "How do you prepare a datacenter migration?" — lower TTLs days ahead, the single most senior-sounding DNS sentence there is. "Every server's healthy but users can't connect — what's your first suspect?" — DNS / nameserver availability, monitored from outside.

The differentiator: naming that DNS is the routing decision that precedes your entire system, and therefore your observability. Candidates who know where their monitoring goes blind are the ones who've been paged by it.

Real-World Engineering Lens

Audit your TTLs against your failover goals. If a record needs 1-minute failover but carries a 24-hour TTL, you don't have failover — you have a 24-hour outage waiting for its trigger.

Lower TTLs before every planned migration, not during. Put it in the runbook as step one, days ahead.

Health-check every failover target. DNS that routes to the dead is worse than DNS that doesn't fail over at all — at least the latter is predictable.

Run DNS from multiple nameservers, ideally multiple providers. The provider outage that takes your whole domain down is a known, preventable failure mode.

Monitor resolution from outside your walls — synthetic checks from several regions (Part 12). Your internal dashboards structurally cannot see a DNS failure.

What's Next

The prologue is written. Users now arrive at the nearest edge, healthy region, closest copy of the system — automatically, invisibly, before a single line of application code runs.

Which sets up the most demanding delivery problem in computing: getting video, the heaviest payload there is, to that global audience, adapting to every device and every fluctuating network in real time.

Blog 17 — Media Streaming and Recommendations: CDN, ABR, and Personalisation. The main series resumes: encoding pipelines, adaptive bitrate, the CDN doing the heaviest lifting in the series, and how recommendations decide what plays next.

Question for Readers

Look up the TTL on your production domain's main record right now.

Now ask: if that server or region failed this minute, how long would part of the internet keep trying to reach the dead address?

That number — not your failover plan, the TTL — is your real recovery time. Most engineers have never checked it.