Who Holds the Steering Wheel? Opacity and Consolidation in CDN Replica Selection

As a first step, Atlas clients resolve CDN-hosted domains using five DNS resolvers chosen to span distinct geographic scopes relative to the client: $(i)$ the same metro area, $(ii)$ a different metro in the same country, $(iii)$ a different country within the same region, $(iv)$ a neighboring region, and $(v)$ a non-neighboring region (Fig. 1).

To illustrate, a client in Brighton, UK could use resolvers located in Brighton (same metro), Maidenhead (same country), Sweden (same region), India (neighboring region), and Argentina (non-neighboring region).²²2While India and Argentina may appear equally distant from the UK geographically, our classification reflects observed network behavior, not physical proximity.

This process is repeated for all CDN-hosted resources of interest. The resulting latency distributions (one per resolver scope) form the basis of our inference methodology.

We begin by illustrating the expected behavior of latency distributions for the three main replica selection strategies.

If a CDN uses DNS-based replica selection, latency distributions will shift based on the geographic scope of the resolver, i.e., resolvers farther from the client will yield replicas farther away (Fig.2(a)). If a CDN uses global anycast, all resolvers will result in similar assignments, regardless of their location (Fig.2(b)). Finally, if a CDN uses regional anycast, resolvers within the same region will yield similar (and low) latencies, while those from other regions will yield higher latencies (Fig. 2(c)).

To systematically characterize replica selection behavior, we define the Coefficient of Regionalization Vector (CRV). This is a 4-element vector measuring the distance between the latency distribution for the client’s local resolver and those for the four progressively more distant resolver scopes.

Formally, $CRV[i]$ is computed as the Kolmogorov–Smirnov (KS) distance between the latency CDF from the local resolver and that from the $i+1$th resolver scope. KS distance measures the maximum vertical difference between two CDFs, ranges from 0 (identical) to 1 (completely different), and makes no assumptions about underlying distribution shape.

We focus primarily on $CRV[1]$ and $CRV[3]$, which capture inter-country and inter-regional variation. These provide the strongest signals for distinguishing between replica selection strategies. Other entries in the CRV may vary depending on CDN deployment granularity but are less decisive. We validated this in Sec. 5 using known CDN behaviors.

We use the CRV pattern to classify each CDN:

• $\mathrm{■}$

  DNS-based: High variation across all scopes $\to$ $CRV[i]\approx 1$

• $\mathrm{■}$

  Anycast: No variation $\to$ $CRV[i]\approx 0$

• $\mathrm{■}$

  Regional anycast: Low CRV within-region (e.g., $CRV[1]\approx 0$), high CRV across regions ($CRV[3]\approx 1$)

Regional scope mismatches (e.g., CDNs defining South America as one region) are mitigated by our multiple-scope design, which allows for fuzzy regional partitioning.

We note that earlier approaches have relied on IP prefix similarity to cluster CDN responses [55, 13], but these require threshold tuning and often struggle with overlapping or sparse deployments. Our latency-based technique avoids these issues by directly observing client-visible variation. As we show in Appendix D, latency yields a more robust and precise signal of selection behavior than IP prefix clustering.

To evaluate ECS support, we issue A-record queries for CDN domains and their CNAME chains using Google Public DNS, a resolver that supports EDNS0 Client Subnet.

Each query includes a spoofed /24 subnet via the edns-client-subnet option – one US-based (e.g., 74.125.0.0/24) and one Asia-based (e.g., 203.0.113.0/24). We then compare the IPs returned. If the responses differ and match the expected geolocation of the provided subnet, we infer that the CDN supports ECS and uses it for replica selection. We also check for non-zero EDNS scope values in the response to confirm ECS metadata is returned.

We begin by applying our methodology to Akamai, a CDN well known for its use of DNS-based replica selection [14, 46, 48]. Using all resources hosted on Akamai, we compute CRV vectors across all countries and analyze the resulting latency distributions.

Figure 3 shows latency CDFs for Akamai-assigned replicas from clients in the UK, India, and the US, for each resolver scope. As expected for DNS-based selection (see Fig. 2(a)), the distributions are cleanly separated across scopes. Corresponding CRV values (Fig. 6(a)) show $CRV[1]$ and $CRV[3]$ between 0.9 and 1.0 – consistent with strong regional sensitivity in replica assignment.

Our analysis clearly confirms Akamai’s use of DNS-based replica selection across all measured countries. In addition, Akamai supports ECS for replica assignment (see § 6.4).

The US-based measurements also highlight a useful edge case: a vantage point in Indianapolis observes similar latencies to replicas assigned via a Canadian resolver and one in San Francisco, despite the >2,000 mi geographic separation. This underscores how CDN infrastructure topology, not just geography, shapes replica selection – and the value of comparative CRV analysis over naive reliance on distance or prefix overlap. It also illustrates a broader point: steering traffic across national borders, even when not strictly necessary for performance, raises questions of jurisdiction and data sovereignty that remain hidden under today’s opaque redirection practices.

Cloudflare is a prominent CDN widely recognized for its use of anycast for replica selection [20, 49]. We apply our methodology to Cloudflare-hosted resources across Brazil, the UK, and India.

Figure 4 shows the latency CDFs for each resolver scope. In all three countries, the latency distributions largely overlap – closely matching the prototypical anycast pattern in Fig. 2(b). The corresponding CRV values (Fig. 6(b)) show $CRV[1]$ and $CRV[3]\approx 0$, confirming Cloudflare’s reliance on global anycast for replica selection.

We next analyze Edgio, one of the few CDNs reported to use regional anycast [44, 51].⁴⁴4EdgeCast (AS15133) and Limelight (AS22822) merged to form Edgio in 2022. We focus here on measurements to the EdgeCast network.

Figure 5 shows the latency CDFs for clients in Brazil, the UK, and Australia. Across all three countries, latency distributions are consistent across resolver scopes within the same region, but diverge sharply for resolvers in non-neighboring regions. This behavior matches the expected pattern of regional anycast (Fig. 2(c)).

The Australia case (Fig. 5(c)) highlights an interesting edge case: resolvers in Sydney and India show overlapping latency distributions. Further analysis revealed that 81% of the measured Edgio objects returned the same IP for both, suggesting they belong to the same anycast region. Personal communication with Edgio operators confirmed this interpretation.

Figure 6(c) shows the corresponding $CRV[1]$ and $CRV[3]$ values. As expected, $CRV[1]$ remains low (0.2–0.3) while $CRV[3]\approx 1$, confirming Edgio’s use of regional anycast for replica selection.

Together, these results demonstrate that our methodology correctly distinguishes the canonical steering approaches. More importantly, they show that we can now apply it to the broader and less transparent ecosystem of global and regional CDNs, cutting through opacity to reveal the steering logics that shape today’s Internet.

We extend our methodology to the remaining CDN providers identified across the top-ranked websites in our dataset. This includes major global CDNs such as Amazon CloudFront and Fastly, as well as regional providers like Azion (Brazil), NGENIX (Russia), and Taobao (China). Google presents a unique challenge due to its hybrid architecture and is discussed separately. Given space constraints, we focus here on representative examples that illustrate the diversity of observed behaviors.

Google presents a complex case that highlights the importance, and limitations, of replica selection inference at scale. Figure 11 shows CDFs of latencies to Google-assigned replicas across resolver scopes for clients in Brazil, Russia, and India. The observed patterns are clearly bimodal: about half of the responses (e.g., $\approx$50% in Brazil) exhibit characteristics of DNS-based selection (divergent latencies), while the rest follow an Anycast-like pattern (overlapping latencies).

This heterogeneity is reflected in Google’s coefficient of regionalization values: for Brazil, Russia, and India, $CRV[1]$ and $CRV[3]$ range between 0.52 and 0.85 (Fig. 9(c)), diverging from the patterns typical of purely DNS-based or anycast approaches. While these mid-range values may initially seem ambiguous, they in fact indicate a genuine hybrid strategy: Google concurrently uses both DNS-based and anycast selection, depending on the resource or customer.

To verify this, we isolate resources matching each pattern. When separated, the resulting CDFs align cleanly with their expected forms: Anycast-based resources exhibit fully overlapping latency distributions and CRVs near zero (Fig. 12), while DNS-based resources show divergent latencies and CRVs near one (Fig. 13). This supports the use of CRV analysis even in the presence of complex, mixed deployments.

We further examined which domains correspond to each selection model. Key Google services (google.com, youtube.com, googleadservices.com, and googlesyndication.com) consistently rely on DNS-based replica selection. In contrast, externally hosted content, e.g., snapchat.com, chess.com, is more often served via Anycast. Table 3 quantifies the split across countries, showing that Google’s replica selection is almost evenly divided between DNS-based and Anycast.

Lastly, we analyzed Google Cloud by isolating responses from IP prefixes Google designates for its cloud services [28]. All of these responses show Anycast behavior, with CRV values $\approx$0. This distinction further underscores the value of our method: not only can it detect mixed strategies across a CDN, but it can also differentiate between infrastructure components or service classes within a provider.

We now examine the global landscape of replica selection strategies across the top 1,000 websites in 19 countries, capturing $\approx$66% of the world’s Internet population. Table 4 reports, per country and region, the percentage of web resources delivered via each approach or a combination. These breakdowns allow us to compare both the technical strategies CDNs employ and the resulting user experience across geographies.

For example, in the US (highlighted), 36.8% of resources rely on DNS-based selection, 23.8% on Anycast, 32.8% on a mixed model, and only 6.5% on Regional Anycast. In contrast, countries like India, Turkey, and those in Africa show a stronger reliance on Anycast. Europe and China exhibit a more balanced mix, often reflecting dominant CDNs like Google that employ hybrid strategies.

To account for the fact that not all resources are equally weighted, we also analyze content volume. Table 5 shows the proportion of total bytes delivered via each mechanism. This byte-weighted view reveals an important trend: across most continents, including North and South America, Africa, and Oceania, DNS-based selection still dominates in terms of content volume, even when Anycast is prevalent by resource count. This suggests that heavier or more critical content (e.g., video, rich media) may still favor DNS-based strategies, possibly due to finer-grained performance tuning.

These trends reflect differences in CDN scale, customer base, and infrastructure. Larger DNS-based CDNs often serve heavier content; Anycast-based CDNs host lighter or static sites.

While our study is scoped to public, unlogged landing pages, the broad adoption of DNS-based selection – especially for large content – suggests that trends are likely to extend to internal or authenticated traffic as well. Future work will explore this hypothesis in depth.

While ECS support is orthogonal to the underlying replica selection mechanism, it remains a critical capability for improving selection granularity – particularly in DNS-based systems. ECS allows CDNs to tailor responses based on a more accurate client location, mitigating issues like client–LDNS mismatch. Understanding ECS support is thus essential for assessing a CDN’s ability to optimize per-user performance.

To detect ECS usage, we issued DNS queries with embedded client subnets to public resolvers and compared the responses from CDN-authoritative nameservers. We then validated whether the selected server locations matched the geolocation of the specified subnet.

Out of the 17 CDNs in our dataset, 10 respond to ECS queries with a scope greater than zero (Table 6), indicating support for the extension. Among these, most also return different server assignments for different subnets, confirming that ECS is used in their replica selection process. In the majority of cases, the geolocation of the assigned server closely matches that of the provided subnet, reinforcing ECS’s role in fine-grained, location-aware request routing.

Table 6 summarizes the predominant replica selection strategy used by each CDN in our dataset. DNS-based selection remains the most common (12 of 17 CDNs), followed by anycast (Cloudflare, StackPath, Fastly, NGENIX), and regional anycast (Edgio, Yahoo). Google and Fastly show mixed behavior, illustrating how a single CDN may adopt different strategies across services or regions.

Though we focus on 17 CDNs, they serve most content across the 19 countries measured. Our methodology generalizes to other providers with sufficient visibility.

We also evaluate ECS support, a complementary mechanism to improve client mapping in DNS-based systems. Ten CDNs respond to ECS queries with non-zero scope and vary responses based on client subnet. In most cases, the assigned replica aligns with the subnet’s geolocation, confirming ECS-informed assignment.

Overall, while selection strategies vary across CDNs and regions, ECS is a widely adopted enhancement among DNS-based systems. The rise of hybrid models and ECS support reflects a shift toward more precise and flexible user steering.

These limits underscore a central point: replica selection remains deliberately opaque. Operators disclose little about how resolvers or clients are mapped to replicas, yet these hidden choices shape traffic flow. By making steering behavior empirically visible, our methodology enables debates that extend beyond performance:

• $\mathrm{■}$

  Resilience: Should global rerouting power rest with a few resolvers and opaque CDN policies? How does this concentration of control affect fault tolerance in times of crisis?

• $\mathrm{■}$

  Sovereignty: When government or regional traffic is steered abroad, what are the implications for jurisdiction and autonomy?

• $\mathrm{■}$

  Control: Does global anycast, while operationally simple, cede too much control to BGP? Do hybrids mixing DNS and anycast compound opacity?

Our measurements cannot answer these questions or reveal operator intent. But by turning replica selection into something measurable, they provide a basis for both scientific classification of CDN strategies and normative debates about accountability in Internet infrastructure.