EDNS Client Subnet Geolocation vs Privacy

As the internet scaled globally and began to support more complex, latency-sensitive services, the need for smarter content delivery mechanisms grew. At the heart of many solutions was DNS, the foundational system that translated human-friendly domain names into IP addresses. But by the early 2010s, it became evident that traditional DNS had a limitation: authoritative name servers often made content routing decisions based on the IP address of the recursive resolver, not the actual client making the request. This posed a challenge for content delivery networks and geographically distributed services aiming to provide the best possible performance. The solution that emerged was the EDNS Client Subnet extension, or ECS, a technical innovation that simultaneously addressed and complicated the dual priorities of performance and privacy.

EDNS Client Subnet was formalized in RFC 7871, published in 2016, and built upon the earlier EDNS0 extension mechanism, which allowed DNS to support features beyond the original protocol limits. ECS added the ability for recursive resolvers to include a portion of the client’s IP address—specifically, a truncated version known as a subnet—in the DNS query sent to the authoritative name server. This gave the authoritative server insight into the client’s rough location, enabling it to return geographically optimized answers. For instance, a user in São Paulo querying for example.com could receive an IP address pointing to a content server in Brazil, rather than one in the United States, resulting in reduced latency, faster load times, and a generally better experience.

The ECS design allowed for flexibility in how much of the client’s address was included. Typically, IPv4 addresses would be truncated to 24 bits, and IPv6 addresses to 56 bits, roughly corresponding to a regional or ISP-level granularity. This meant that the authoritative server could make location-based decisions without needing the client’s exact IP address. The system struck a balance—providing better performance than traditional DNS without fully exposing users’ network identity. For services reliant on fine-tuned geolocation, such as video streaming platforms or online gaming networks, ECS offered a significant leap in capability.

However, the benefits of EDNS Client Subnet came with substantial privacy concerns. Critics argued that even partial IP address exposure could enable tracking or profiling, especially if queries were observed over time or correlated with other data. Unlike traditional DNS, where the recursive resolver acted as a privacy boundary between client and authoritative server, ECS effectively pierced that boundary. The authoritative server, potentially operated by a third party with no direct relationship to the user, could now see data indicative of the user’s location or network affiliation. In an era increasingly sensitive to surveillance and data collection, this was seen as a serious tradeoff.

Privacy advocates also worried about the implications of ECS in relation to data retention policies, advertising tracking, and jurisdictional overreach. Because ECS data could be logged or shared, it potentially expanded the digital footprint of users in ways that were neither transparent nor controllable from their perspective. Moreover, unlike application-level geolocation permissions—where users might consent to sharing location data—ECS operated silently in the background, often without any user knowledge or control.

In response to these concerns, various DNS resolver operators and privacy-conscious organizations implemented mitigations. Some public resolvers, such as Cloudflare’s 1.1.1.1 and Quad9, chose to either disable ECS by default or severely limit its use. Instead of forwarding client subnets to all authoritative servers, they opted to use ECS only for whitelisted domains or within their own infrastructure. These policies aimed to preserve the performance benefits of ECS in controlled environments while preventing widespread exposure of user subnet data. At the same time, content providers that relied on ECS for performance tuning faced challenges, as the lack of consistent ECS support across resolvers could degrade the precision of their geolocation models.

The debate over EDNS Client Subnet sits at the core of a broader tension in internet architecture: the desire to optimize user experience through contextual awareness versus the imperative to protect user privacy against passive and active data collection. It reflects the reality that every layer of the internet stack—from transport protocols to naming systems—has privacy implications, and that even seemingly innocuous optimizations can have wide-reaching consequences. ECS highlighted the fact that DNS, often taken for granted as a background service, plays a pivotal role in how information flows across the network and how identities can be inferred.

As encrypted DNS transport protocols like DNS over HTTPS (DoH) and DNS over TLS (DoT) gained traction, the role of ECS came under further scrutiny. While these protocols encrypt the DNS query in transit, protecting it from intermediaries like ISPs or on-path attackers, they do not necessarily prevent ECS data from being included in the query sent from the recursive resolver to the authoritative server. This created a paradox where users might think they were protected by encryption while still leaking approximate location data through ECS. The privacy models of DNS encryption and ECS were, in many respects, in tension with one another.

Going forward, the future of ECS may lie in more nuanced implementations that respect user preferences, regulatory boundaries, and operational requirements. Some propose the use of adaptive ECS, where recursive resolvers determine on a per-query basis whether to include client subnet data based on domain, policy, or explicit user configuration. Others suggest extending ECS to include privacy-preserving techniques such as anonymized or randomized subnetting. Yet, these approaches add complexity and require broad cooperation among DNS operators, which remains a significant barrier to standardization and adoption.

In retrospect, EDNS Client Subnet was a bold attempt to reconcile two competing values—performance and privacy—within the fabric of the DNS protocol. It succeeded in delivering tangible benefits for content localization and network efficiency, but at the cost of challenging assumptions about user anonymity and trust in the DNS infrastructure. Whether ECS is seen as a net positive or a cautionary tale depends largely on one’s priorities. For some, it represents the kind of pragmatic engineering compromise that keeps the internet running smoothly. For others, it is a reminder that optimization should never come at the hidden expense of user control and transparency. In either case, ECS has become a lasting part of the conversation about how DNS should evolve in an internet defined as much by trust and rights as by speed and efficiency.

As the internet scaled globally and began to support more complex, latency-sensitive services, the need for smarter content delivery mechanisms grew. At the heart of many solutions was DNS, the foundational system that translated human-friendly domain names into IP addresses. But by the early 2010s, it became evident that traditional DNS had a limitation: authoritative…