EDNS Client Subnet: Geo-DNS, CDNs, and Privacy Trade-Offs

Every DNS answer you get is shaped by where resolvers think you are, not just who you are. That’s why a movie site points you to a nearby CDN node while a game update comes from a different edge. The plumbing that helps with this is EDNS Client Subnet (ECS): a way for recursive resolvers to pass a short prefix of your network to authoritative servers so they can return topologically close endpoints.

That convenience isn’t free. ECS moves some bits of your network identity to places that wouldn’t otherwise see it, which has privacy consequences and subtle caching side effects. Used well, ECS trims latency and reduces cross-continent detours; used carelessly, it leaks too much and fragments caches.

Let’s unpack how ECS works, how CDNs and geo-DNS engines use it, and the practical ways you can tighten or switch it off without breaking reachability.

How EDNS Client Subnet Works

ECS is an EDNS(0) option carried in the OPT record with option code 8. A recursive or forwarding resolver can add it to upstream queries with three fields: address family (IPv4 or IPv6), a source prefix length (how many address bits are included), and an address value that is zeroed beyond that prefix. Authoritative name servers that understand ECS treat this as a hint to pick a tailored response (for example, choose an A/AAAA that maps to a closer edge) and echo ECS in the reply with a scope prefix length describing the client subnet range for which that answer is valid.

Caching hinges on that scope. A resolver must cache the answer keyed not only by QNAME/QTYPE but also by the ECS scope so it reuses the data only for clients whose subnets match. Broader scopes improve cache hit rates but risk misrouting some users; narrow scopes increase precision but explode the cache and raise upstream load.

Why CDNs and Geo-DNS Use ECS

Without ECS, authorities only see the resolver’s address. If that resolver is centralized or anycasted far from you, geo-routing can be wrong, steering traffic to a distant edge. ECS restores enough topology signal to make better choices. Large CDNs often resolve hostnames to different IPs by region, ISP, or even network distance; an ECS prefix lets them group many clients into the same locality bucket and still allow useful caching.

Typical Prefix Lengths and Scopes

Practical deployments keep the client prefix short: commonly up to /24 for IPv4 and up to /56 for IPv6. Those lengths preserve a coarse neighborhood without revealing a specific host. Authoritative servers should pick scope lengths that reflect how widely a response applies—often wider than the client source prefix for non-tailored data—to avoid over-fragmented caches. Negative answers and delegations should carry ECS with a global /0 scope so resolvers can cache them widely and resolve predictably.

Privacy and Security Trade-Offs

ECS exposes part of the client’s network to every upstream involved in the resolver→authority leg, including any on-path observer. Transport encryption between you and your resolver (DNS over HTTPS or DNS over TLS) prevents local eavesdroppers from seeing your queries but does not prevent the resolver from adding ECS to its upstream query. Name minimization reduces how much of the domain each hop sees, and EDNS(0) padding hides size fingerprints on encrypted DNS, but neither disables ECS because the option is explicit metadata.

Who Actually Sends ECS

Policies vary by resolver. Some public resolvers implement ECS to help localization and cap prefixes to protect privacy. Others are privacy-centric and never send ECS to authorities. A few resolvers offer multiple endpoints so you can opt in or out; for example, one endpoint may send ECS while the default does not. The net effect is that two users on the same network can receive different CDN IPs depending on the resolver brand and endpoint they use.

How to Limit or Disable ECS Exposure

You can act at three layers: resolver choice, resolver configuration, and protocol choice.

Choose a Resolver That Doesn’t Emit ECS

The simplest move is to pick a public resolver that documents “no ECS to authorities” and stick to that endpoint. You still get anycast reachability to a nearby resolver, but the authority will only see the resolver’s address, not a prefix from your network.

Tune Your Own Recursive

If you run a recursive on a router, server, or as an enterprise forwarder, check the ECS defaults. Many modern recursors disable ECS by default or let you control it. If you must enable it for performance-sensitive zones, cap the prefix (for example, IPv4 /24, IPv6 /56), restrict ECS to vetted targets or specific domains, and make sure your cache partitions by ECS scope to avoid cross-leaks between client populations.

Use Encrypted DNS—and Consider Oblivious DoH

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the leg between your stub and resolver, preventing passive observers on the local path from inferring your lookups. However, if the resolver emits ECS upstream, authorities still learn a client prefix. If you want to make it impossible for the target resolver to link your address to your query, Oblivious DoH (ODoH) splits knowledge between a proxy and a target so no single entity sees both. In that model, the target can’t add an accurate ECS prefix because it doesn’t know your IP, effectively neutralizing ECS at a modest latency cost.

Operational Guidance for Zone and CDN Operators

If you manage authoritative DNS and plan to use ECS, consistency beats cleverness. Always echo ECS in responses that received it (including negatives and referrals), use global scope (/0) for data that isn’t actually tailored, and avoid overlapping scope prefixes that create ambiguous caching. Validate both IPv4 and IPv6 behaviors; many breakages stem from failing the IPv6 half. Measure cache hits and end-user latency before and after enabling ECS, and be ready to widen scopes if you see churn without user-visible gain.

Balancing Accuracy With Cache Health

Start with modest granularity (for example, IPv4 /24, IPv6 /56) and widen the scope prefixes you return so resolvers can reuse answers broadly. Watch edge cases: mobile networks (rapidly changing prefixes), CGNAT deployments (many users share a /24), and split-horizon enterprise DNS. ECS is a hint, not an identity; combine it with server-side telemetry like round-trip times, not just geo-IP, when choosing edges.

Quick Testing and Debugging

You can test ECS paths in a few ways. On the command line, modern dig supports “+subnet=addr/prefix” to send a client prefix; “+subnet=0.0.0.0/0” explicitly signals opt-out. Compare results with and without a subnet and note which edge IPs you get. Browser-based tools can reveal the public IP that sites and CDNs think you’re coming from, and many CDN debug hostnames echo which data center is serving you. For developers, log whether your authoritative servers echo ECS correctly and verify that negative and referral responses include ECS with appropriate /0 scope for caching.

When to Turn ECS Off

If your users don’t see latency or throughput benefits, or if your privacy posture forbids leaking any network bits beyond your resolver, turn it off. For end users, pick a resolver that doesn’t emit ECS. For operators, disable it entirely or whitelist only the domains where the gain is measured and repeatable.