DNS & Request Routing

Every request starts with a question the user never sees: given the name example.com, what IP address do I actually connect to? The Domain Name System (DNS) answers it. DNS is the internet’s phone book, but it is much more than a lookup table — it is also the first routing decision in the entire request path, the place where you decide which of your servers, in which part of the world, a given user should reach. Get this layer right and users land on a nearby, healthy machine before your application has run a single line of code.

Why names exist at all

Computers route on numbers — IP addresses like 203.0.113.34. Humans cannot remember numbers, and, just as important, numbers change: you redeploy, you move data centres, you fail over. A stable name with a swappable number behind it is a layer of indirection, and indirection is the oldest trick in computing for buying flexibility. The cost of that indirection is an extra round trip (the lookup) and a new thing that can be stale or wrong (the cached record).

From name to IP: the resolution chain

A name is resolved through a hierarchy, walked top-down, the first time nobody has it cached:

   Your device
      │  "A record for www.example.com?"
      ▼
   Recursive resolver (your ISP's, or 1.1.1.1 / 8.8.8.8)
      │   ───►  Root servers:   "ask the .com servers"
      │   ───►  TLD servers (.com): "ask example.com's nameservers"
      │   ───►  Authoritative NS for example.com: "it's 203.0.113.34"
      ▼
   Answer cached at every hop, then returned to your device

The recursive resolver does the legwork and, crucially, caches the answer. The authoritative nameserver is the source of truth — it holds the actual records you publish. The first lookup walks the whole chain (tens of milliseconds, sometimes more); every lookup after that, until the cache expires, is nearly instant.

Record types you must know

DNS stores typed records. A handful do almost all the work:

Record	Maps name to	Used for
A	IPv4 address	the classic name → IP
AAAA	IPv6 address	same, for IPv6
CNAME	another name	aliasing (www → example.com)
NS	a nameserver	delegating who is authoritative
MX	a mail server	email routing
TXT	arbitrary text	domain verification, SPF/DKIM

A common pattern: point your domain at a load balancer or CDN with a CNAME, so the actual IPs can change underneath you without touching your domain’s records.

TTL: the dial between freshness and load

Every record carries a TTL (time-to-live) in seconds — how long resolvers may cache it before asking again. TTL is a single dial with a direct trade-off:

• Long TTL (e.g. 24 hours): fewer lookups, less load on your nameservers, faster average resolution — but a change (like a failover to a new IP) takes up to a full TTL to reach everyone.
• Short TTL (e.g. 60 seconds): changes propagate fast, so failover is quick — but every resolver re-asks constantly, raising load and average latency.

The pre-migration TTL trick

Before a planned IP change or data-centre migration, lower the TTL days in advance (say to 60s). Resolvers gradually pick up the short TTL, so when you flip the record, the change propagates in a minute instead of a day. Afterwards, raise it back up. This is the standard playbook for clean cutovers.

What does TTL buy us, and what does it cost? A long TTL buys low load and latency at the cost of slow change propagation; a short TTL buys fast failover at the cost of higher query volume. There is no universally right value — only the right value for how often you expect to change.

Routing users with DNS: anycast and GeoDNS

DNS isn’t just whether you get an IP — it’s which IP, and that makes it a routing tool.

Anycast — one IP, many locations

With anycast, the same IP address is announced from many data centres at once. The internet’s own routing (BGP) delivers each user’s packets to the topologically nearest announcement. One address, dozens of physical front doors; the network silently picks the closest. If a location goes down, its route is withdrawn and traffic shifts to the next-nearest — failover with no DNS change at all. This is how public resolvers (1.1.1.1) and CDNs put an edge near everyone.

GeoDNS — different answers by location

With GeoDNS, the authoritative nameserver looks at where the query came from and returns a different IP accordingly: European users get the Frankfurt IP, US users get the Virginia IP. The routing decision is made at resolution time, in the DNS answer itself.

   Anycast:  everyone resolves the SAME IP; the network routes them to the nearest copy.
   GeoDNS:   everyone resolves a DIFFERENT IP, chosen by their geographic location.

GeoDNS is also where health-aware routing lives: a managed DNS provider can health-check your endpoints and simply stop handing out the IP of a region that’s failing. The catch is the same TTL problem — a user (or resolver) holding a cached answer keeps using the dead region until the TTL lapses. Anycast sidesteps this because failover happens in the network layer, below DNS caching.

DNS is cached everywhere, including places you don’t control

Your TTL is a request, not a command. Browsers, operating systems, and corporate resolvers all cache, and some ignore short TTLs or pin records far longer than you asked. Never assume a DNS change is fully propagated just because your TTL elapsed — design failover so that a stale DNS answer degrades gracefully (e.g. the old IP still works for a while during a cutover).

Where DNS sits in the stack

DNS resolves to an IP that usually belongs to a load balancer, a CDN edge, or a reverse proxy — not directly to an app server. So DNS makes the coarse routing decision (which region, which entry point) and those blocks make the fine decision (which specific server). The two layers compose: GeoDNS gets you to the right continent; a load balancer gets you to the right machine.

It actually happened — the 2016 Dyn attack took DNS hostage

On 21 October 2016, a massive DDoS from the Mirai botnet — hundreds of thousands of hijacked webcams and home routers — slammed Dyn, a major managed-DNS provider. Dyn ran the authoritative nameservers for Twitter, Reddit, Spotify, GitHub, Netflix and others, so when DNS resolution failed, all of those sites became unreachable at once — not because they were down, but because nobody could look up their addresses. It is the cleanest demonstration that DNS is a critical dependency hiding in plain sight: your app can be perfectly healthy and still be invisible if the name layer in front of it falls over.

It actually happened — Facebook withdrew its own routes (October 2021)

On 4 October 2021, a faulty configuration change during routine maintenance caused Facebook’s backbone routers to withdraw the BGP routes that advertised its network — including the routes to its own authoritative DNS servers. Those nameservers were anycast (the very technique above), but anycast depends on BGP announcing the address: once the announcements vanished, the DNS servers had no path to the internet, and facebook.com, Instagram, and WhatsApp became unresolvable for roughly six hours. The outage was worsened because internal tools — even some badge access — leaned on the same infrastructure. The lesson pairs with the anycast section above: routing is what makes a name reachable, so a routing mistake and a DNS outage can be the same event.

The architect’s lens

DNS is the one block you can’t not use — but how you configure it (TTLs, anycast vs GeoDNS) is a real choice, so run it through the five questions:

• Why does it exist? Because computers route on numbers humans can’t remember and that change on every redeploy, data-centre move, and failover. DNS gives a stable name with a swappable number behind it — a layer of indirection that buys flexibility.
• What problem does it solve? Name→IP resolution and the first, coarse routing decision: anycast and GeoDNS steer each user to the nearest healthy endpoint before your application runs a single line of code, then a load balancer makes the fine choice of machine.
• What are the trade-offs? The TTL dial: a long TTL buys low load and fast average resolution but slow change propagation (a failover takes up to a full TTL to reach everyone); a short TTL buys quick failover at the cost of constant re-querying. And your TTL is a request, not a command — resolvers and OSes cache in places you don’t control.
• When should I avoid relying on it? For fast failover. Because cached GeoDNS answers keep sending users to a dead region until the TTL lapses, push sub-second failover down into the network layer (anycast/BGP), below the DNS cache, rather than expecting a DNS record flip to take effect instantly.
• What breaks if it fails? Everything — even perfectly healthy apps. When Dyn was DDoSed (2016) and when Facebook withdrew its own BGP routes (2021), the services were up but invisible, because the name layer in front of them couldn’t answer.

Check your understanding

1. Why do we use names at all when computers route on IP addresses? What does that layer of indirection buy and cost?
2. Walk a cold DNS lookup through the resolution chain. Which component is the source of truth, and which one does the caching?
3. State the TTL trade-off in one sentence. Why do you lower the TTL before a planned migration?
4. Contrast anycast and GeoDNS: in each, does every user resolve the same IP or a different one, and at which layer does failover happen?
5. Why can a stale DNS cache keep sending users to a dead region under GeoDNS but not (as easily) under anycast?

Show answers

1. Humans can’t remember numbers, and IPs change when you redeploy, move data centres, or fail over. A stable name with a swappable number behind it is a layer of indirection that buys flexibility; it costs an extra round trip (the lookup) and a new thing that can be stale or wrong (the cached record).
2. Device → recursive resolver → root → TLD (.com) → authoritative nameserver, with the answer cached at every hop. The authoritative nameserver is the source of truth (it holds the records you publish); the recursive resolver does the legwork and caches, so only the first lookup walks the whole chain.
3. A long TTL buys low load and fast average resolution but slow change propagation; a short TTL buys fast failover but higher query volume. You lower the TTL before a planned migration so resolvers pick up the short value in advance, and the actual cutover then propagates in a minute instead of a day.
4. Anycast: everyone resolves the same IP, and the network (BGP) routes each user to the nearest copy — failover happens in the network layer, below DNS caching. GeoDNS: everyone resolves a different IP chosen by location — failover happens at resolution time, in the DNS answer.
5. Under GeoDNS the routing decision lives in the cached DNS answer, so a resolver holding the dead region’s IP keeps using it until the TTL lapses. Under anycast everyone shares one IP and rerouting happens in the network the instant a route is withdrawn — below the DNS cache — so a stale cache can’t pin users to a dead region.