EDNS Client Subnet ECS explained

How ECS works

Most internet users do not query authoritative nameservers directly. They send a query to a recursive resolver, which asks the authoritative server on their behalf. The resolver sits in some data centre, and if it is far from the user, a geo-aware authoritative server would answer for the resolver's location rather than the user's, which is wrong for services like CDNs that return a nearby edge address.

EDNS Client Subnet (ECS), defined in RFC 7871, lets a recursive resolver attach a truncated prefix of the end user's IP to the query it forwards. The authoritative server can then choose a geographically appropriate answer based on that prefix instead of guessing from the resolver's IP. The resolver also marks the answer with a scope prefix so it knows how broadly it may cache the result.

The mechanism is opt-in at each resolver, and many resolvers only send ECS to authoritative servers known to understand it, which limits exposure to zones that will not echo back more information than was sent.

Prefix rules

RFC 7871 sets how much network information may be shared:

• Recursive resolvers truncate IPv4 source prefixes to at most 24 bits and IPv6 prefixes to at most 56 bits when they add ECS for a client.
• A client can ask that less be shared by sending an explicit ECS option with a shorter prefix, down to zero.
• When a response includes an ECS option, the resolver caches it only for the scope the authoritative server declares. A response without an ECS option is treated as a scope of zero, that is, valid for all clients.

In practice resolvers add the ECS option transparently for the end user, so most people never see it. The parts that matter to web and DNS operators are the scope-bound caching and the fact that a single resolver may deliberately answer differently for two clients that reach the same authoritative zone.

Privacy trade-offs

ECS improves geo-accuracy but hands upstream nameservers a hint about where the user sits. Because of that, the groups behind the RFC intentionally published it as informational rather than a community consensus recommendation, and operators are told not to echo back more address bits than they were given.

Practical guidance for site and DNS owners:

• Enable ECS support at authoritative servers when the zone serves geo-dependent answers, so CDN-style splitting works for users who are far from their resolver.
• Confirm the resolver ASP or hosting panel does not leak more than the 24/56-bit standard when forwarding ECS.
• Remember that ECS does not change DNS propagation or DoH transport; it only refines which answer a resolver returns.

Understanding the roles of name servers makes it easier to see where in the chain ECS is added and why it is invisible to most browsers.