Summary

  • EDNS Client Subnet allows an intermediate resolver to place a truncated client-network prefix in an upstream DNS query, replacing the resolver's own address as the only locality hint.
  • The resolver controls how many source-prefix bits it discloses; an authoritative server returns a scope prefix that governs how broadly the tailored answer may be reused in cache.
  • The option does not prove geography, identity or consent. RFC 7871 documented privacy and cache costs, while RFC 8932 later advised privacy services to avoid ECS or minimize and disclose its use.

The query the user did not send

Before ECS, a topology-sensitive authoritative server saw the source address of the recursive resolver. That might approximate the client network when resolver and user were close, but a centralized resolver could serve clients far from its own network position. An answer tailored to the resolver could therefore be a poor answer for the person behind it.

RFC 7871 documented an EDNS0 option that lets an intermediate nameserver forward information about the query's origin network. The resolver is not forwarding a full account of the client. It sends an address family, a source prefix length and only enough address bits to cover that prefix. In a query, scope prefix length is zero. The option makes the resolver's intervention explicit in the packet, even though it can remain transparent to the stub resolver and end user.

That transparency is the article's central governance fact. The upstream disclosure is normally made by an intermediary, using a policy about how many network bits are useful and acceptable. The client benefits, if the authoritative service can use the hint to choose a better response, but the client is not the party negotiating with that authority.

Two prefix lengths, two decisions

SOURCE PREFIX-LENGTH states how many leading bits of the address are significant in the query. A recursive resolver has a configured maximum cacheable length and should use less than the full address. If the incoming query already carries a shorter ECS prefix, an onward resolver must not disclose more client bits than that limit. The address field is truncated accordingly and padded only through its final necessary octet.

SCOPE PREFIX-LENGTH plays a different role in the response. It says how many leading bits define the network for which the answer is intended. A shorter scope says the answer can cover a broader range. A longer scope can signal that the source prefix supplied to the authority was not specific enough to select the most appropriate tailored answer.

Neither number proves location. RFC 7871 distinguishes topological distance from geography: machines far apart on a map may be close in network terms, and neighbours may be distant through the network. Nor does the option define how an authority chooses a tailored response. Scope governs reuse of the answer; it does not certify that the selected server is nearest, fastest or best.

The cache becomes part of the protocol

An ECS-aware cache still begins with the ordinary DNS tuple of name, type and class. It then chooses among cached answer sets using prefix matching. Answer records are tied to the network described by the response, and the relationship between source length, scope length and the resolver's maximum cache length determines how an entry can be reused.

If the response contains no ECS option, a resolver normally treats it as scope /0, suitable for all client addresses. If an authority returns REFUSED, an ECS-aware resolver retries without ECS so it can distinguish refusal of the option from other uses of the same response code.

This extra dimension has a cost. Different networks can require different cached answers for the same name, type and class. RFC 7871 warns of larger caches, lower reuse and greater server load. It recommends enabling ECS only where clients gain a clear benefit, keeping it off in default configurations and limiting how many networks and answers are retained.

An opt-out whose path matters

A stub resolver can send ECS with SOURCE PREFIX-LENGTH zero. A recursive resolver receiving that instruction must not place the client's address information in its upstream query. It may omit ECS or use its own address information instead. Forwarding resolvers must preserve an incoming limit rather than widening the disclosure.

The wire rule is clear, but RFC 7871's 2016 privacy note also recorded that practical support for expressing the preference was limited at the time. That observation is historical, not a current adoption claim. The source set here contains no present census of applications, public resolvers or operator policies.

RFC 8932 reframed the problem for DNS privacy services in 2020. Encryption protects the client-to-resolver transport from certain observers, but the resolver still sees queries and can send information onwards. The BCP says a service should honour a zero source prefix and should either avoid ECS upstream or offer a service that does not send it. If an operator does use ECS, it should choose the shortest operationally feasible prefix, ideally restrict the upstream servers that receive it and disclose the prefix length and policy.

Privacy and DNSSEC are different controls

DNSSEC does not turn the prefix into authenticated client context. RFC 7871 recommends that most DNSSEC records be scoped at /0, while an RRSIG remains tied to the RRset it signs. Validation can protect DNS data according to DNSSEC's rules; it does not sign the resolver's choice to disclose a prefix, prove geography or certify the authority's locality policy.

The historical lesson is therefore not that ECS defeated DNS privacy or guaranteed better delivery. It is that a locality optimisation made two intermediary policies durable: what the resolver reveals on the user's behalf, and how the authority partitions later cache reuse. That is an editorial inference from the protocol mechanics, not a measurement of how networks deploy ECS today.

Sources