Anycast vs DNS Routing: How a CDN Picks the PoP

Evaluated February 2026. Two mechanisms decide which edge serves a request, and they fail on completely different timescales. An anycast CDN hands the decision to BGP, which reconverges in roughly 2–30 seconds after a route withdrawal. DNS routing hands the decision to resolvers, whose caches push practical failover to 30–300 seconds even when the authoritative TTL is 20 seconds. Anycast wins on failover speed and cold-start latency; DNS steering wins on granularity, per-user control, and multi-CDN. Most large 2026 deployments run both: DNS selects the region, anycast selects the machine inside it.

If you are short-listing vendors, the routing model is not a footnote in the architecture diagram. It determines how fast you recover from a bad edge, whether you can drain 20% of a location, and how badly your latency numbers degrade for users behind public resolvers.

Anycast CDN vs DNS routing: how each one actually picks an edge

Anycast CDN routing: BGP decides, and BGP does not measure latency

An anycast CDN announces the same prefix from many locations. The client never chooses; every transit network and peer between the client and the CDN runs its own best-path selection over local preference, AS path length, MED, and IGP cost. Latency is not an input to that algorithm. It is a frequent side effect, not a guarantee.

That is why anycast produces excellent medians and ugly tails. Hot-potato routing inside a transit provider can hand a subscriber in one metro to an edge two countries away because that is where the provider's cheapest handoff sits. You cannot fix it with a config change; you fix it with peering, prefix deaggregation, or BGP communities that influence upstream selection.

DNS routing CDN behavior: resolver geography, ECS, and the TTL floor

A DNS routing CDN answers a query with a hostname or address chosen by an authoritative server that sees, at best, the recursive resolver's address. EDNS Client Subnet (RFC 7871) improves this by passing a truncated client prefix, commonly an IPv4 /24. Coverage is partial: several major public resolvers send client subnet data, at least one large privacy-focused resolver deliberately does not, and corporate forwarders often strip it.

The control is real. You can weight a region at 5% increments, pin a customer to a specific stack, steer by ASN, or shift traffic between two CDNs on a dashboard. The cost is a resolution chain that adds a measurable first-request penalty on cold cache, typically 20–80 ms across two or three CNAME hops in 2026 measurements, plus a failover floor set by health-check interval, TTL, resolver cache, and client-side caching you do not control.

Evaluation criteria for CDN PoP selection

Six criteria separate the models in an evaluation. Assumptions: global consumer traffic, mixed HTTP/2 and HTTP/3, origin in one region, a compliance requirement that some traffic stays in-region.

• Cold-start latency: time from first DNS query to first byte, not steady-state RTT.
• Failover time: measured from edge failure to the client's first successful request, not from the vendor's alert.
• Load control granularity: can you drain a fraction of a location, or only all of it?
• Session stability: what happens to long-lived HTTP/2 and WebSocket connections during a routing change.
• Multi-CDN compatibility: whether a second vendor can be inserted without re-architecting.
• Observability: whether you can prove which edge served a request, from the outside.

The single most important conclusion: anycast recovers roughly an order of magnitude faster than DNS routing, but only DNS routing lets you move a defined fraction of traffic on purpose.

Vendor comparison: who routes how in 2026

The takeaway from the table: pure-anycast vendors give you the fastest recovery with the least steering control, while DNS-mapping vendors give you the opposite, and price per TB varies by more than an order of magnitude across the same routing models.

BlazingCDN. Priced as flat pay-as-you-go tiers rather than per-region rate cards, with a 100% uptime SLA, NVMe SSD edge storage, and roughly one-hour onboarding for a standard HTTP pull configuration. Stability and fault tolerance sit in the same class as Amazon CloudFront while costing substantially less per TB, which matters most to enterprises moving hundreds of terabytes of software builds, game patches, or video. Honest limitation: the routing mechanics are not documented publicly at the level Cloudflare or Fastly publish, so put "describe the edge selection and failover path" in your RFP and validate it in the bake-off below rather than assuming.

Cloudflare. The reference implementation of anycast at scale, with the deepest peering and the most public writing about how it behaves. Limitation: steering granularity is coarse by design, and bandwidth economics are opaque enough that year-three costs are hard to model.

Fastly. Anycast plus a genuinely programmable edge; the best fit when routing decisions need to happen in code after the connection lands. Limitation: list pricing is high, so the economics only work with a committed volume deal.

Amazon CloudFront. DNS-based selection with tight integration into the rest of the AWS control plane, and an optional anycast address range for customers who need stable IPs for allowlisting. Limitation: on-demand list pricing is the most expensive per TB in this set, and the 99.9% monthly SLA is weaker on paper than the 100% SLAs elsewhere.

Akamai. Decades of investment in measurement-driven DNS mapping; still the strongest option when you need per-network steering in places where BGP paths are poor. Limitation: procurement and configuration cycles are long, and nothing is self-serve.

Bunny.net, CDN77, Gcore, Medianova. Cost-competitive alternatives in the same league on price, with capable routing for mainstream web and video workloads. Limitation: routing behavior differs between their products, and published SLA terms vary by tier, so read the specific contract rather than the marketing page.

Worked cost math at two volumes

Assumptions: 2026 published list pricing, North America and Europe delivery, no private discount applied, cache hit ratio irrelevant to egress billing.

BlazingCDN prices egress as flat pay-as-you-go tiers: as of 2026, $350 per month covers up to 100 TB ($3.50 per TB) and $4,000 per month covers up to 2,000 TB ($2.00 per TB), both with a 100% uptime SLA. For comparison, Amazon CloudFront's published on-demand tiers work out to roughly $7,050 for the same 100 TB in North America and Europe before any private pricing agreement.

At 2,000 TB per month the gap narrows in percentage terms because CloudFront's list tiers fall toward $20–$30 per TB, but the absolute monthly difference still runs into five figures. Negotiated enterprise contracts compress this; the routing model you choose does not change the bill, so evaluate routing and price as separate line items. If you want the full per-TB breakdown alongside routing behavior, the CDN comparison of price per TB and edge routing is the faster starting point than assembling six rate cards by hand.

Recommendation matrix: which routing model fits which workload

The pattern across the matrix: pick anycast when recovery speed matters more than placement control, and DNS routing when you must be able to say exactly where a given user's traffic went.

FAQ: anycast CDN and DNS routing for CDN PoP selection

Is anycast routing faster than DNS-based CDN routing?

Anycast is usually faster on first request because it removes the DNS resolution chain, which costs roughly 20–80 ms on a cold cache in 2026 measurements. Steady-state latency depends on peering quality, not the routing model. A well-peered DNS-mapped network can beat a poorly peered anycast network in any given metro.

How long does DNS-based CDN failover take?

Plan for 30–300 seconds end to end. The chain is health-check detection interval, authoritative record change, TTL expiry at the recursive resolver, and finally client or runtime caching that may ignore the TTL entirely. Anycast failover skips all four steps and completes in BGP reconvergence time, typically 2–30 seconds.

Does EDNS Client Subnet fix DNS routing accuracy?

EDNS Client Subnet (RFC 7871) narrows the error substantially but does not eliminate it. Coverage is incomplete: some large public resolvers do not send client subnet data on privacy grounds, and enterprise forwarders often strip the option. Traffic from those paths is still mapped by resolver location, which can be hundreds of kilometres from the user.

Can multi-CDN work with an anycast CDN?

Yes, but the switching layer has to sit above the anycast layer. You either steer with DNS above two anycast vendors, accepting DNS failover timing, or you select CDN hostnames inside your own application or video player, which gives per-session switching but only for clients you control.

How do you test which edge location a CDN selected?

Resolve the hostname from multiple networks, then read the vendor's edge identification response header on an HTTP HEAD request and compare it against the TCP or QUIC handshake round-trip time. Run a traceroute from the same vantage point to see which transit network made the path decision. Repeat during peak hours, when routing and capacity pressure both change.

Run this bake-off before you sign

Two weeks, two vendors, four measurements. First, resolve the test hostname from at least 30 networks across your top five markets and record the answers plus TTLs. Second, measure handshake round-trip time at p50, p95, and p99 per market, not just the average. Third, capture the edge identity header for every request so you can prove which site served it. Fourth, ask each vendor to drain one location during a scheduled window and time the gap from last error to first successful request. Whoever refuses step four has answered the routing question for you.