DNS and global traffic routing

The Domain Name System (DNS)

Before a client can send an HTTP request or establish a TCP handshake, it must translate a human-readable domain name (such as api.fjell.dev) into an IP address (198.51.100.42).

DNS is hierarchical:

• Recursive resolvers, provided by your ISP or a public service (for example Google Public DNS at 8.8.8.8), walk the hierarchy on the client's behalf and cache what they learn.
• Root servers (.): 13 named root server identities (A to M), run by 12 independent organizations and served from about 2,000 instances worldwide.
• Top-level domain (TLD) servers for .com, .io, .org and so on.
• Authoritative nameservers hold a domain's records: A (name to IPv4 address), AAAA (IPv6), CNAME (name to another name), NS (which servers are authoritative) and MX (mail servers).

Lower-level servers, browsers and operating systems all cache answers, for a period set by the record's time to live (TTL). Cached answers can go stale until it expires.

Global traffic routing policies

Managed DNS services such as Route 53 and Cloudflare can choose the answer per query:

1. Latency-based routing

For resources in several regions, return the region that offers the user the best latency (Route 53 routes to "the Region that provides the best latency"). A resolver in Frankfurt typically gets the European address; one in California gets US West.

2. Geolocation routing

Answer based on where the user is, for example to keep EU users in the EU.

3. Weighted round robin and canary routing

Split answers in set proportions (e.g., $90\%$ to the current cluster, $10\%$ to a canary). Also used to drain servers before maintenance, balance clusters of different sizes, and run A/B tests.

4. Failover with health checks

Health checkers probe each endpoint; after a number of consecutive failures you configure, DNS stops returning that address and answers with a standby instead. Route 53, for example, runs checkers in many locations and treats an endpoint as unhealthy when 18% or fewer of them see it as healthy.

Anycast: one address, many places

With unicast, an IP address belongs to one location. With anycast, the same address is announced from many locations using BGP, and the Internet's routing system delivers each packet to one of them, normally the nearest in routing terms. Several root server operators, and public resolvers such as 8.8.8.8, use anycast to spread one address across many sites. One caveat: the nearest location in routing terms is not always the one with the lowest round-trip time, so anycast does not guarantee the fastest path.

The DNS TTL trade-off

Even a low TTL is not instant: an answer cached before you lowered the TTL lives out its old TTL, which is why you lower it well before a planned change.

DNS has costs too: each lookup adds a little delay (mitigated by caching), and DNS services have themselves been taken down by DDoS attacks, making sites unreachable by name.