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 93.184.216.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 93.184.216.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.

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?