Content Routing Mechanisms: DNS, Anycast, and HTTP Redirect

Content routing is the process by which a CDN directs each user request to the optimal edge server. Rather than sending every visitor to a single origin, a CDN evaluates factors such as geographic proximity, server load, network conditions, and content availability to select the best endpoint. The routing mechanism a CDN employs determines how quickly and accurately this selection happens, directly impacting latency, reliability, and cache efficiency across the network.

Understanding the differences between DNS-based routing, anycast, HTTP redirect routing, BGP-based routing, and application-layer routing is essential for architects who need to evaluate CDN providers or build custom delivery infrastructure. Each mechanism operates at a different layer of the network stack, carries distinct tradeoffs in latency and granularity, and suits different operational requirements.

What Is DNS-Based Routing and How Does It Work?

DNS-based routing is the foundational content routing mechanism used by virtually every commercial CDN. When a browser requests cdn.example.com, the query reaches the CDN's authoritative DNS server. That server inspects the source IP address of the DNS resolver (or the EDNS Client Subnet data if available) and returns the IP address of the edge server it deems optimal for that user.

The decision logic within the DNS server typically considers multiple signals. Geographic proximity is the primary factor: the DNS server maps the resolver's IP to a geographic region using databases like MaxMind GeoIP and returns the nearest edge server. Beyond geography, sophisticated DNS-based routing systems incorporate real-time health data, server load metrics, and network latency measurements to make smarter decisions.

DNS-based routing has an important limitation: it relies on the IP address of the DNS resolver, not the end user. When a user in Tokyo queries through a DNS resolver located in San Francisco, the CDN may route them to a West Coast edge server instead of a Tokyo PoP. EDNS Client Subnet (ECS) partially addresses this problem by allowing resolvers to forward a truncated version of the client's IP address, giving the CDN better geographic signal. However, not all resolvers support ECS, and privacy-focused resolvers may strip this data.

The TTL (Time to Live) set on DNS responses creates another consideration. A short TTL (30-60 seconds) allows the CDN to re-route users quickly when conditions change, but increases DNS query volume. A longer TTL reduces DNS load but makes the system slower to react to server failures or traffic shifts. Most CDNs use TTLs between 30 and 300 seconds, balancing agility against DNS overhead. For more on TTL optimization, see DNS TTL and Propagation.

How Does Anycast Routing Work at the Network Layer?

Anycast routing takes a fundamentally different approach by operating at the network layer rather than the application layer. In an anycast deployment, the CDN assigns the same IP address to edge servers in multiple geographic locations. Each location announces this IP address to the global routing table via BGP (Border Gateway Protocol). When a user sends a packet to the anycast IP, the internet's routing infrastructure naturally delivers it to the topologically nearest announcing location based on BGP path selection.

The mechanics of anycast rely on how BGP selects routes. When multiple autonomous systems advertise the same IP prefix, routers choose the path with the shortest AS path length, the lowest multi-exit discriminator (MED), or other BGP selection criteria. In practice, this usually means packets are delivered to the physically or topologically nearest data center, though BGP does not optimize for latency directly.

Anycast provides exceptional resilience. If an edge server goes offline and stops announcing its BGP routes, traffic automatically shifts to the next closest announcing location. This failover happens at the network level within seconds, without any DNS TTL delays or application-layer intervention. This property makes anycast particularly valuable for DDoS protection, where traffic is absorbed across many distributed locations simultaneously.

Cloudflare, for example, uses anycast across its entire network. Every one of their data centers announces the same IP ranges, meaning a DNS query, an HTTPS request, and a DDoS packet all flow to the nearest PoP automatically. This simplifies operations because there is no per-user routing decision to make at the DNS level.

The primary limitation of anycast for HTTP traffic is session persistence. TCP connections are stateful, and if BGP routes shift mid-connection, packets may arrive at a different data center that has no knowledge of the existing TCP session. CDNs mitigate this with techniques like ECMP (Equal-Cost Multi-Path) stabilization and connection migration protocols. For UDP-based protocols like QUIC/HTTP3, anycast works more naturally because QUIC connections are identified by connection IDs rather than IP tuples.

What Is HTTP Redirect Routing and When Should You Use It?

HTTP redirect routing operates at the application layer. The user's initial request arrives at a routing server (or any edge server), which examines the full HTTP request including headers, cookies, URL path, query parameters, and the client's IP address, then returns an HTTP 302 redirect pointing the client to the optimal edge server's URL.

This mechanism provides the highest granularity of any routing approach. Because the routing decision happens after the HTTP request is received, the CDN has access to application-layer context that DNS and anycast cannot see. For example, a video CDN can route users to different servers based on the specific video file requested, ensuring that popular content is served from servers with warm caches while long-tail content routes to servers with the specific file available.

The tradeoff is latency. HTTP redirect routing adds one complete round trip to the request flow: the client sends the initial request, receives a 302 response, then sends a second request to the redirect target. This overhead of 50-200ms is acceptable for large file downloads and streaming sessions where the redirect cost is amortized over a long-lived connection, but prohibitive for small API calls or web page loads where every millisecond matters.

Major video CDNs and download services commonly use HTTP redirect routing. When a user clicks a download link, the initial request hits a global routing server that evaluates server load, geographic proximity, and content availability before redirecting the user to the best mirror. This pattern is visible when download URLs change between retries or when inspecting network requests during video playback initialization.

How Does BGP-Based Routing Steer CDN Traffic?

BGP-based routing extends beyond simple anycast by using BGP communities and route manipulation to actively steer traffic between CDN locations. Rather than passively relying on BGP's natural shortest-path selection, the CDN manipulates BGP attributes such as AS path prepending, MED values, and community tags to influence where traffic flows.

For example, a CDN can prepend additional AS hops to routes announced from an overloaded data center. This makes the BGP path appear longer, causing upstream routers to prefer shorter paths to other data centers. The effect is a gradual shift of traffic away from the congested location without taking it offline entirely. This technique requires careful implementation because BGP convergence takes 30-90 seconds and overly aggressive prepending can cause traffic oscillation.

BGP-based traffic engineering is most commonly used by large CDN providers that operate their own autonomous systems and maintain peering relationships with hundreds of ISPs. Providers like Akamai, Cloudflare, and Limelight use BGP communities to signal routing preferences to their peering partners, enabling fine-grained control over traffic paths across the internet.

What Role Does Application-Layer Routing Play?

Application-layer routing makes content delivery decisions based on request content, user attributes, or business logic. Unlike DNS or anycast routing, which operate before or during connection setup, application-layer routing happens after the request reaches an edge server. The edge server itself decides whether to serve the request locally, proxy it to another edge, or fetch from origin.

Common application-layer routing decisions include serving different content based on the Accept-Language header, routing authenticated users to specific backend pools, splitting traffic for A/B testing, or directing requests for uncached content to an origin shield rather than going directly to origin. This logic typically runs in edge compute environments such as Cloudflare Workers, Fastly Compute, or AWS Lambda@Edge.

Application-layer routing is also essential for traffic management policies such as rate limiting, bot detection, and geo-blocking. These decisions require inspecting HTTP headers, TLS fingerprints, or request patterns, which are only available at the application layer.

How Do Routing Mechanisms Compare?

Each routing mechanism has distinct characteristics that make it suitable for different scenarios. The following table summarizes the key differences:

How Are Routing Mechanisms Combined in Practice?

Production CDN architectures rarely rely on a single routing mechanism. Instead, they layer multiple approaches to balance performance, resilience, and flexibility. A typical modern CDN uses the following layered approach.

The first layer is DNS-based routing with EDNS Client Subnet support. When a user resolves the CDN hostname, the DNS infrastructure returns the IP address of the nearest cluster of edge servers. This provides coarse geographic steering with minimal latency.

The second layer is anycast within each cluster. The IP addresses returned by DNS are anycast addresses shared across multiple servers or PoPs within a region. This provides automatic load distribution and instant failover at the network level.

The third layer is application-layer routing at the edge. Once a request arrives at an edge server, application logic determines whether to serve from local cache, proxy to a peer edge server, route through an origin shield, or apply security policies. This layer handles the fine-grained decisions that DNS and anycast cannot make.

This layered architecture means that the journey of a single CDN request involves multiple routing decisions at different network layers, each optimizing for a different objective. DNS provides geographic affinity, anycast provides resilience, and application-layer routing provides intelligence.

What Latency Tradeoffs Should You Consider?

The choice of routing mechanism directly affects end-to-end latency. DNS-based routing adds latency only during the initial DNS resolution, which is typically cached for the TTL duration. Subsequent requests within the TTL window incur zero routing overhead. Anycast adds no measurable latency because routing happens within the network fabric. HTTP redirect routing consistently adds one round trip, making it unsuitable for latency-sensitive applications but acceptable for streaming and downloads.

For latency-critical applications, the optimal strategy combines DNS-based routing with anycast and avoids HTTP redirects entirely. For content delivery scenarios where cache hit rates and content availability matter more than first-byte latency, HTTP redirect routing provides superior server selection that justifies its latency cost.

The key insight is that no single routing mechanism is universally optimal. The best CDN architectures select the routing mechanism, or combination of mechanisms, that aligns with their specific performance requirements, operational constraints, and traffic patterns. Understanding these tradeoffs allows you to evaluate CDN providers and custom architectures with precision rather than relying on marketing claims.