When you load a webpage from a major website, the content probably isn’t coming from a single server in a single data center. It’s coming from whichever edge server is closest to you — one of potentially thousands scattered across the globe. The technology that makes this possible? DNS.
Content Delivery Networks (CDNs) have turned DNS from a simple name-to-address lookup into a sophisticated traffic routing system. Every DNS response becomes a routing decision, and that decision happens billions of times per day.
The Problem CDNs Solve
Without a CDN, a user in Tokyo requesting content from a server in New York faces roughly 200ms of round-trip latency — just for the speed of light through fiber optic cable. Add TCP handshake, TLS negotiation, and actual data transfer, and you’re looking at a painfully slow experience.
CDNs solve this by caching content at edge locations around the world. But placing servers everywhere is only half the problem. The other half: how do you route each user to the right server? That’s where DNS becomes the CDN’s traffic controller.
Anycast: One Address, Many Servers
Anycast is the foundational routing technique behind modern CDNs. The idea is deceptively simple: announce the same IP address from multiple locations, and let the internet’s routing infrastructure (BGP) naturally send each user to the nearest one.
Here’s how it works:
- A CDN deploys servers in data centers worldwide — say, 200 locations
- Each location announces the same IP prefix via BGP to its upstream providers
- When a user’s packets are destined for that IP, BGP routing tables direct them to the topologically nearest announcement
- The user connects to whichever server is closest in network terms
User in Tokyo ──BGP──▶ CDN Edge (Tokyo) ← Same IP: 198.51.100.1
User in London ──BGP──▶ CDN Edge (London) ← Same IP: 198.51.100.1
User in São Paulo ──BGP──▶ CDN Edge (São Paulo) ← Same IP: 198.51.100.1
Anycast is elegant because it requires zero DNS intelligence — the routing happens at the network layer. The DNS server itself can be anycast, meaning even the DNS resolution step is handled by the nearest server. Cloudflare’s 1.1.1.1 resolver uses anycast, as do the root DNS servers (which is why 13 logical root server identities can actually represent hundreds of physical servers).
Anycast for DNS vs. Anycast for Content
There’s an important distinction. Anycast works beautifully for DNS (which is mostly UDP — short, stateless queries) and quite well for TCP-based content delivery thanks to modern techniques. Early concerns about anycast and TCP (BGP route changes mid-connection could break sessions) have been largely mitigated through careful BGP engineering and connection migration protocols like QUIC.
GeoDNS: Location-Aware Resolution
While anycast operates at the network layer, GeoDNS operates at the DNS layer. The DNS server examines the source IP of the query (or the resolver’s IP) and returns different answers based on the geographic location.
A GeoDNS-enabled authoritative server might work like this:
Query: cdn.example.com A
Source: 203.0.113.50 (geolocated to Japan)
Response: 198.51.100.10 (Tokyo edge server)
Query: cdn.example.com A
Source: 192.0.2.75 (geolocated to Germany)
Response: 198.51.100.20 (Frankfurt edge server)
GeoDNS providers maintain databases mapping IP ranges to geographic locations (using data from Regional Internet Registries and commercial geolocation providers). The accuracy is generally good at the country level, decent at the city level, and unreliable below that.
Latency-Based Routing
Geography isn’t always the best proxy for network performance. A user in Portland, Oregon might have lower latency to a server in San Jose than to one in Seattle, depending on peering arrangements.
Latency-based routing improves on GeoDNS by using actual network performance data. The DNS server maintains a matrix of latency measurements between resolver networks and edge locations, then returns the answer with the lowest measured latency.
AWS Route 53’s latency-based routing is a well-known implementation. The system continuously measures latency between AWS regions and resolver networks, updating routing decisions in near real-time.
EDNS Client Subnet: Fixing the Resolver Problem
Traditional GeoDNS has a fundamental flaw: it sees the resolver’s IP address, not the user’s IP address.
Consider this scenario: A user in Miami uses Google Public DNS (8.8.8.8). Their DNS query goes to a Google resolver — which might be in a data center in Atlanta. The CDN’s GeoDNS sees the Atlanta IP and routes the user to an Atlanta edge server instead of a closer Miami one.
EDNS Client Subnet (ECS), defined in RFC 7871, fixes this. It allows recursive resolvers to include a truncated version of the client’s IP address in the DNS query:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 203.0.113.0/24/0
The /24 means only the first three octets are sent — enough for geographic routing without revealing the user’s exact IP. The authoritative server uses this subnet to make a better routing decision, and the resolver caches the answer scoped to that subnet.
ECS Trade-offs
ECS is powerful but controversial:
- Privacy: Even a /24 prefix narrows the user’s location significantly. RFC 7871 explicitly discusses this concern
- Cache fragmentation: Without ECS, a resolver caches one answer per domain. With ECS, it might cache hundreds of answers (one per client subnet), dramatically increasing memory usage
- Complexity: Both resolvers and authoritative servers must support ECS for it to work
Cloudflare has notably chosen not to use ECS for 1.1.1.1, citing privacy concerns. Instead, they rely on their anycast network — since the resolver itself is close to the user, its IP is already a good proxy for user location.
How CDNs Put It All Together
In practice, major CDNs use a combination of all these techniques:
- Anycast for DNS resolution — the user’s DNS query reaches the nearest CDN nameserver
- GeoDNS + ECS for intelligent routing — the nameserver returns the optimal edge server IP
- Health checking — unhealthy edge servers are automatically removed from DNS responses
- Real-time traffic data — routing decisions factor in server load, not just geography
- TTL tuning — short TTLs (30-60 seconds) allow rapid rerouting when conditions change
A typical CDN DNS response might look like this:
cdn.example.com. 30 IN A 198.51.100.10
cdn.example.com. 30 IN A 198.51.100.11
The 30-second TTL means the CDN can redirect traffic within a minute if that edge location fails or becomes overloaded. This is a deliberate trade-off: short TTLs mean more DNS queries (more load on authoritative servers) but faster failover.
The Scale of CDN DNS
To appreciate how central DNS is to CDN operations, consider the numbers. Cloudflare handles approximately 50 million DNS queries per second. Akamai’s DNS infrastructure serves a similar scale. Every one of these queries is a routing decision — choosing which of potentially hundreds of edge locations should serve a particular user.
This makes CDN DNS infrastructure some of the most sophisticated and heavily engineered systems on the internet. They must be:
- Fast — adding latency to DNS defeats the purpose of a CDN
- Reliable — if DNS fails, the entire CDN fails
- Intelligent — bad routing decisions mean poor user experience
- Scalable — handling millions of queries per second with sub-millisecond response times
Key Takeaways
- Anycast routes users to the nearest server at the network layer by announcing the same IP from multiple locations
- GeoDNS makes routing decisions at the DNS layer based on the querier’s geographic location
- Latency-based routing improves on GeoDNS by using actual performance measurements
- EDNS Client Subnet (RFC 7871) lets resolvers share truncated client IPs for better routing, at the cost of privacy and cache efficiency
- CDNs combine all these techniques with health checking and traffic data for optimal routing
- Short TTLs enable fast failover but increase DNS query volume
DNS has evolved from a phone book into a real-time traffic management system. Next, we’ll look at how these same principles apply to load balancing and failover — even without a CDN.