Summary

  • The proposed ECS opt-in option gives a client a way to permit and cap address-prefix disclosure without knowing the public address seen by a resolver, but an ordinary response is not proof that the resolver understood or honoured it.
  • Consent has to survive resolver forwarding and cache custody: the option is deliberately non-transitive, and an answer obtained with ECS must not cross into a client context that never opted in.

A client sends a DNS query with a new EDNS option. The option says that the recursive resolver may forward part of the client's network address, but no more than 24 bits. A response arrives on time. The application opens. A monitoring system records the query as successful.

None of those events proves that the limit was accepted.

The first revision of Client Opt-In Signaling for EDNS Client Subnet, dated 20 August 2026, makes that uncomfortable compatibility fact explicit. A resolver that implements the proposal returns the option with an effective prefix limit. A resolver that does not implement it follows the ordinary EDNS rule for an unknown option: ignore it and answer as it would have anyway. The same visible outcome—an answer—can therefore sit on top of two opposite privacy states.

This is an individual Internet-Draft, not a DNSOP Working Group document or an RFC. Its masthead says “Intended status: Experimental”; the proposed option code is still TBD, and the text does not establish deployment. Its value is not as proof of a finished standard. It is as a clean demonstration that preference, receipt and outcome are different control objects.

ECS begins with resolver discretion

EDNS Client Subnet, defined in RFC 7871, lets a recursive resolver send a prefix of a client's network address to authoritative DNS servers. Those servers can use the prefix to tailor an answer, often to direct a user toward nearby infrastructure. The address fragment is useful precisely because it carries location and network information beyond the recursive resolver.

The existing model normally leaves the choice with resolver configuration. A client can opt out by sending an ECS option whose SOURCE PREFIX-LENGTH is zero. A client can also request a shorter nonzero prefix, but the ECS format requires an address from which those bits are taken. A device behind NAT, carrier-grade NAT or a VPN may know only a private address, not the public source address the recursive resolver sees.

The proposed option separates permission from address supply. A client can include a one-octet maximum without naming an address. The resolver then uses the source address it observes and calculates the effective limit as the smallest of the client's cap, any limit in a supplied ECS option, its own maximum cacheable prefix and the address-family maximum. For IPv4 that final ceiling is 32; for IPv6 it is 128.

The zero-length form is subtly different. It opts in but supplies no client maximum, leaving the resolver's own maximum to govern. That is valid consent, but it is not precise minimisation. If the client permits nothing, the draft says it should omit the option. An explicit value of zero also causes no forwarding, although on an unencrypted path it advertises that the client implements the mechanism.

The receipt belongs to the resolver

When an implementing resolver accepts a valid option, its response includes a one-octet value reporting the effective limit. That field is useful. It can distinguish a resolver claiming zero disclosure from one claiming a positive ceiling. It can also signal implementation support.

But the value is the resolver's own statement. EDNS OPT records are not covered by DNSSEC signatures. The client has not received an independently authenticated account of what left the resolver. A hostile or compromised service can forward 32 bits, report 16 and still return a DNSSEC-valid answer for the requested name.

Encrypted DNS narrows the threat without changing that institutional fact. DNS over TLS, HTTPS or QUIC can prevent an on-path attacker from adding the option, raising its limit or falsifying the returned value on the client-to-resolver hop. Encryption does not make the resolver honest. The only direct evidence of what it disclosed is observation at, or near, the authoritative side.

This gives operators a useful evidence ladder. The client records the instruction it sent. The encrypted session records who received it and whether traffic was protected in transit. The resolver reports the limit it says it applied. Authoritative telemetry, where legitimately available, records the ECS prefix actually received. Each rung answers a different question. Compressing them into “privacy preference honoured” discards the boundaries that make accountability possible.

Consent cannot be forwarded as a credential

The new option is intentionally non-transitive. A recursive resolver must not copy it into the queries it sends to authoritative servers. EDNS is negotiated hop by hop, and this instruction is addressed to the resolver that directly receives the client's query. Authoritative servers still see an ordinary ECS option, not a portable declaration of consent.

The rule matters when resolvers forward to other resolvers. A forwarding resolver is itself a client of its upstream service. It may send a new opt-in option upstream, but it cannot set a limit larger than its client allowed. If it constructs the ECS option itself, it reports how many original-client address bits it forwards. If it leaves address selection to the upstream resolver, the address disclosed is the forwarder's address, not the original client's; it must report zero client-address bits.

This is thin coordination by design. The first resolver cannot manufacture an end user's mandate for an arbitrary chain. It can make a bounded operational decision of its own, under a ceiling it received. Each boundary retains an owner.

An ordinary ECS option does not solve that problem. A forwarding resolver may add ECS for the clients it serves, so the presence of ECS says nothing about whether the originating device chose it. Under the proposal, ECS without the separate opt-in option does not authorize an implementing resolver to forward client address information.

The cache can violate consent without sending a prefix

The sharpest part of the draft is not the new wire field. It is the cache rule. An implementing resolver must not return an answer obtained using ECS to a client that is not a signaling client. It must know, for each cache entry, whether ECS was used to obtain it.

Without that provenance, a tailored answer fetched for one network can be returned to another client that never opted in. The resolver sends no new prefix upstream during the cache hit, yet it has allowed the consequence of an earlier disclosure to cross the consent boundary. No field in the DNS answer marks it as tailored. The receiving client cannot reconstruct the history from the packet.

Separate caches for signaling and non-signaling clients are one straightforward implementation. Other designs can carry equivalent provenance and eligibility rules. The architectural requirement is the same: consent status must be part of cache custody, not merely a transient property of the initiating query.

For signaling clients, RFC 7871 longest-prefix matching remains. A cached entry with a source prefix longer than the current client's effective limit may still answer that client, because serving it does not send additional address bits upstream. That distinction is easy to miss. The limit controls disclosure, not every use of data previously obtained under ECS. A defensible audit must therefore record both how the entry was acquired and why it was eligible for this requester.

The cache hit exposes a measurement gap

The response value in revision 00 is the effective prefix limit calculated for the query, whether or not the answer came from cache. That is a policy ceiling. It need not be the number of bits used to obtain the particular answer. The draft itself leaves open whether the response should instead report actual bits used, especially for cache hits.

This is more than a field-definition debate. A ceiling answers “what may the resolver disclose for this query?” Actual use answers “what disclosure contributed to this answer?” On a cache hit, the first can be positive while the second is zero for the current exchange. Reporting one as the other makes compliance dashboards look precise while mixing permission with event history.

The same caution applies to registry progress. The requested option code is TBD. An eventual Expert Review assignment would make interoperable implementation easier, but it would not prove that resolver caches preserve provenance, that forwarding limits remain intact or that deployed services report honestly. Registry assignment is coordination, not operational certification.

Privacy is bounded, not abolished

A short ECS prefix is not anonymous. It can reach every authoritative server to which the recursive resolver sends ECS, as well as observers of unencrypted upstream traffic. RFC 7871 places limits and recommendations around that distribution, but a client should still choose the shortest useful cap and understand that the prefix identifies a network region.

The proposed opt-in reverses the default for an implementing resolver: no option means forward nothing. That is a meaningful shift in control. It does not erase the trust relationship with the recursive service. The client already exposes its queries to that service; the new field asks the same service to constrain an additional disclosure.

The governing question is therefore not whether the option exists. It is whether every control point preserves the claim it is actually qualified to make. The client can prove what it requested. The resolver can attest what it says it did. Encryption can prove protection against certain intermediaries. Cache provenance can explain why an answer crossed a context. Authoritative observation can show what prefix arrived.

The answer arriving is only evidence that resolution completed. It is not evidence that the resolver accepted the limit, kept consent local, segregated its cache or disclosed no more than the client permitted. Those conclusions require receipts from the places where the corresponding decisions were made.

Sources