Network Working Group B. Farrokhi Internet-Draft J. Todd Intended status: Experimental Quad9 Expires: 21 February 2027 20 August 2026 Client Opt-In Signaling for EDNS Client Subnet draft-farrokhi-dnsop-ecs-opt-in-00 Abstract EDNS Client Subnet (ECS) lets a recursive resolver send part of a client's network address to authoritative servers, which tailor their answers to it. A resolver's configuration decides whether it does so, for every client that sends no ECS option of its own. RFC 7871 lets a client opt out. Asking instead for a shorter prefix requires the client to supply the address those bits are taken from, which a client behind a NAT or a VPN does not know. This document defines an opt-in. A client includes an EDNS(0) option in a query to ask the resolver to forward its address information, and can use that option to limit how many address bits the resolver forwards. A resolver implementing this document forwards nothing for a client that does not send the option, and one that does not implement it ignores the option. One resolver address can then serve clients that want tailored answers and those that want their addresses withheld. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 February 2027. Farrokhi & Todd Expires 21 February 2027 [Page 1] Internet-Draft ECS Client Opt-In August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. The ECS Opt-In Option . . . . . . . . . . . . . . . . . . . . 4 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 3.3. Recursive Resolver Behavior . . . . . . . . . . . . . . . 5 3.3.1. Response . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Relationship to the ECS Option . . . . . . . . . . . . . 8 3.5. Non-Transitivity . . . . . . . . . . . . . . . . . . . . 9 4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Deviations from RFC 7871 . . . . . . . . . . . . . . . . . . 10 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 15 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction EDNS Client Subnet [RFC7871] lets a recursive resolver send a prefix of the client's network address to authoritative servers, which use it to tailor their answers. A resolver either uses ECS or it does not, based on how it is configured. A client of a resolver with ECS enabled can opt out by sending an ECS option with a SOURCE PREFIX-LENGTH of 0, which Farrokhi & Todd Expires 21 February 2027 [Page 2] Internet-Draft ECS Client Opt-In August 2026 Section 7.1.2 of [RFC7871] obliges the recursive resolver to honor. That client can also ask for a shorter prefix, but Section 6 of [RFC7871] requires the ECS option to contain the address those bits are taken from, and a client behind a NAT or a VPN does not know the address the resolver sees. A client that sends nothing has its address information forwarded. An operator who wants to offer ECS to some clients and withhold it from others runs a second resolver on a second address and tells users which one to use. That increases the operational burden, resource usage and complexity. It also hands the privacy decision to whoever configures the client's resolver address, which is usually not the user whose address is forwarded. This document defines an opt-in mechanism. A recursive resolver that implements it forwards a client's address information only for a query that includes the opt-in option, and that option can also limit how many address bits the resolver forwards. The resolver reports in its response how many it applied. 1.1. Scope This document defines the signal and the resolver behavior it requires. It does not change the ECS option and does not define any new behavior for authoritative servers. A resolver implementing it treats some recommendations of [RFC7871] differently, which Section 5 lists. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. DNS terminology follows BCP 219 [RFC9499]. ECS terminology follows [RFC7871] and is not redefined here. This includes SOURCE PREFIX- LENGTH, SCOPE PREFIX-LENGTH, Tailored Response, Intermediate Nameserver, and Forwarding Resolver, none of which [RFC9499] defines. The term "signaling client" means a client whose query included the option defined in this document and for which the effective prefix length defined in Section 3.3 is nonzero. Farrokhi & Todd Expires 21 February 2027 [Page 3] Internet-Draft ECS Client Opt-In August 2026 3. The ECS Opt-In Option 3.1. Option Format This document specifies a new EDNS(0) [RFC6891] option by which a client asks the resolver to forward its address information. OPTION-CODE for this option is TBD. OPTION-LENGTH MUST have a value of 0 or 1 for queries and MUST have the value 1 for responses. [RFC7314] and [RFC7828] likewise define options whose length differs between queries and responses. OPTION-DATA, where present, is a single field: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | PREFIX-LENGTH | +---+---+---+---+---+---+---+---+ Figure 1: OPTION-DATA Format for the ECS Opt-In Option PREFIX-LENGTH is an unsigned 1-octet field. In a query it is the largest number of address bits the client permits the resolver to forward. A query that omits OPTION-DATA sets no such limit. In a response it is the effective prefix length defined in Section 3.3, the largest number of address bits the resolver may forward for that query. The option has no address family field. The resolver interprets PREFIX-LENGTH in the address family of the address it forwards. 3.2. Client Behavior A client that wants to permit the resolver to forward a prefix of its address MUST include exactly one instance of this option in the query. To limit how many address bits the resolver forwards, it uses the one-octet form. With the zero-length form the resolver's own maximum applies, as Section 3.3 describes. A client that permits nothing to be forwarded SHOULD omit the option. A PREFIX-LENGTH of 0 forwards nothing either, but on an unencrypted transport it tells anyone on the path that the client implements this specification. Farrokhi & Todd Expires 21 February 2027 [Page 4] Internet-Draft ECS Client Opt-In August 2026 A client MAY include an ECS option in the same query. A client that knows the public address it is seen as coming from can supply it that way. A client that does not know that address can still set a limit with the one-octet form, which does not need one. Section 3.4 specifies how the two options interact. A client SHOULD NOT supply a private address in an ECS option, because Section 3.3 has the resolver forward nothing for such a query. A client that supplies an address and receives a value of 0 can retry with the one-octet form. A client MUST treat this option as absent in a response whose OPTION- LENGTH is not 1, and in a response that includes more than one instance of it. Neither case tells the client what the resolver forwarded. A client MUST NOT treat the arrival of a response as evidence that its limit was honored. A resolver that does not implement this option ignores it, per Section 6.1.2 of [RFC6891], and answers as it would have anyway. Section 7 covers how much a client can trust the reported value. 3.3. Recursive Resolver Behavior A resolver implementing this document MUST NOT forward a client's address information for a query that does not include this option. For a query that includes this option, the resolver selects the address to forward. Where the query also includes an ECS option with a nonzero SOURCE PREFIX-LENGTH and a FAMILY of 1 or 2, the resolver takes FAMILY and ADDRESS from that option, which Section 7.1.1 of [RFC7871] permits, and MUST NOT use a different address. Otherwise it uses the source address of the query, so a client need not know the address the resolver observes. Section 11.2 of [RFC7871] requires a response to mirror the ECS fields of the query. A resolver that used a different address would therefore indicate that its answer is tailored for the network the client named when it had asked about another, the anomaly Section 7.5 of [RFC7871] describes. The resolver then calculates an effective prefix length, the smallest of * the PREFIX-LENGTH in the query, if it used the one-octet form, * the SOURCE PREFIX-LENGTH of an ECS option, if the query included one, Farrokhi & Todd Expires 21 February 2027 [Page 5] Internet-Draft ECS Client Opt-In August 2026 * the resolver's own maximum cacheable prefix length, and * the maximum prefix length of the address family of the selected address, that is 32 for IPv4 and 128 for IPv6. The resolver MUST NOT forward more bits of that address than the effective prefix length. Section 7.1.1 of [RFC7871] already combines two of these four the same way, having the resolver use the shorter of the incoming SOURCE PREFIX-LENGTH and its own maximum cacheable prefix length. Where the query includes an ECS option whose FAMILY is neither 1 nor 2, the effective prefix length for that query is 0. Section 6 of [RFC7871] defines the address format only for FAMILY 1 and FAMILY 2, so the resolver has no address to take from that option. Using the source address it observed instead would produce the anomaly described above. A resolver SHOULD NOT forward an unroutable address supplied by a client, such as one from the special-purpose blocks [RFC6890] defines, or a routable address the query source is known not to serve. Section 11.3 of [RFC7871] recommends treating an unroutable address as equivalent to the resolver's own identity, and ignoring and never forwarding an address the query source is known not to serve. This document has the resolver forward nothing in either case, which is documented under Section 5. A client behind a NAT that does not know it is behind one supplies an unroutable address. Where the resolver does not forward the supplied address, the effective prefix length for that query is 0. A resolver MAY decline to forward a client's address information for any query, a choice Section 5 of [RFC7871] leaves with the resolver. The effective prefix length for such a query is 0. If the effective prefix length is nonzero, the resolver constructs an ordinary ECS option as described in Section 7.1.1 of [RFC7871], with FAMILY and ADDRESS from the selected address and SOURCE PREFIX-LENGTH set to the effective prefix length. The rest of the exchange, including how the resolver handles the authoritative server's SCOPE PREFIX-LENGTH, follows [RFC7871] unchanged. The resolver MUST treat the query as though this option were absent, and therefore forward nothing, in each of the following cases: * OPTION-LENGTH is greater than 1 * more than one instance of the option is present Farrokhi & Todd Expires 21 February 2027 [Page 6] Internet-Draft ECS Client Opt-In August 2026 This departs from the usual handling of a malformed EDNS option. Section 6 of [RFC7871] recommends FORMERR for a malformed ECS option, and [RFC7873] and [RFC9660] specify FORMERR for their own options. This document does not, because the option is an optional privacy control. A client that encodes it incorrectly would lose name resolution altogether, whereas treating the option as absent forwards nothing and lets resolution continue. A PREFIX-LENGTH larger than the family maximum is not an error. The calculation above reduces it to the family maximum. 3.3.1. Response If the query included this option and the resolver did not treat it as absent, the response MUST include exactly one instance of it, with PREFIX-LENGTH set to the effective prefix length. If the query did not include this option, or the resolver treated it as absent under Section 3.3, the response MUST NOT include this option. The resolver forwarded no address information for that query and therefore did not use ECS, so the response requirements of Section 7.2.2 of [RFC7871] do not apply, as Section 3.4 explains. The client receives the response it would have received from a resolver that does not implement ECS. If the query included an ECS option and the effective prefix length is nonzero, the response MUST include an ECS option, as Section 7.2.2 of [RFC7871] requires of a resolver that uses ECS. Its FAMILY, ADDRESS and SOURCE PREFIX-LENGTH are those of the query, which Section 11.2 of [RFC7871] requires as a countermeasure against birthday attacks. That requirement holds even where the resolver forwarded fewer address bits upstream than the query contained. SCOPE PREFIX-LENGTH reports the scope of the answer. Otherwise the response MUST NOT include an ECS option. The reported value is the effective prefix length computed for that query, and it does not depend on whether the answer came from cache. A client that sent the option can distinguish three cases from the response. An absent option means the resolver does not implement this specification, or that the option was removed in transit. Such a resolver may still use ECS of its own accord. A value of 0 means the resolver implements this specification and will forward nothing. A value of N means the resolver will forward at most N bits of that client's address. Farrokhi & Todd Expires 21 February 2027 [Page 7] Internet-Draft ECS Client Opt-In August 2026 3.4. Relationship to the ECS Option The two options have different roles, and a query may include either or both. This option asks the resolver to forward the client's address information. An ECS option supplies the address to forward and, in its SOURCE PREFIX-LENGTH, a limit of its own. An ECS option cannot state a nonzero limit without an address. Section 6 of [RFC7871] requires ADDRESS to hold the client's address truncated to SOURCE PREFIX-LENGTH bits, and a stub resolver behind a NAT, a carrier-grade NAT, or a VPN may not know its actual outbound address that is exposed to the resolver. The private address it does know is no substitute, because Section 11.3 of [RFC7871] recommends against forwarding such an address and Section 3.3 then forwards nothing for the query. Such a client sets its limit with the one- octet form of this option that does not need an address. When both options state a limit, the smaller governs, as Section 3.3 specifies. A larger value in this option cannot raise the ECS limit, because Section 7.1.2 of [RFC7871] forbids an Intermediate Nameserver to send more bits of client address than the originating query included. An ECS option on its own is not an opt-in. For a query that includes one and no instance of the opt-in option, the resolver forwards nothing, as Section 3.3 requires. A Forwarding Resolver may add an ECS option for the clients it serves, as Section 7.1.3 of [RFC7871] describes, so an ECS option says nothing about what the client that sent the query wants. A resolver never forwards this option (Section 3.5), so only that client can have added it. Section 7.1.1 of [RFC7871] and Section 7.5 of [RFC7871] tell a resolver to return REFUSED when it will not use a client's ECS option. A resolver implementing this document answers the query instead. It MUST NOT refuse a query solely because the query included an ECS option without this option. Section 7.5 of [RFC7871] already makes an exception of this kind, noting "that a query MUST NOT be refused solely because it provides 0 address bits". Section 7.2.2 of [RFC7871] states its response requirements for the case "When an Intermediate Nameserver uses ECS". This document reads that condition per query, so the requirements do not apply to a query for which the resolver forwards nothing. Each value below is further limited by the maximum prefix length of the address family, and a resolver that declines under Section 3.3 forwards nothing in any of these cases. Farrokhi & Todd Expires 21 February 2027 [Page 8] Internet-Draft ECS Client Opt-In August 2026 +==========================+========================================+ | Query includes | Bits of the client's address forwarded | +==========================+========================================+ | neither option | none | +--------------------------+----------------------------------------+ | an ECS option only | none | +--------------------------+----------------------------------------+ | this option, zero- | the resolver's maximum | | length | | +--------------------------+----------------------------------------+ | this option, one | the smallest of N and the resolver's | | octet N | maximum | +--------------------------+----------------------------------------+ | both options | the smallest of all limits present | +--------------------------+----------------------------------------+ Table 1: Address Bits Forwarded for Each Combination of Options 3.5. Non-Transitivity A resolver MUST NOT include this option in queries it sends to authoritative servers, and MUST NOT copy it from a client query into any upstream query. Section 1 of [RFC6891] describes EDNS as a hop-by-hop extension, negotiated between each pair of hosts in the resolution process, and Section 6.1.1 of [RFC6891] forbids forwarding an OPT RR. This option is an instruction to the recursive resolver that receives the query. It means nothing to an authoritative server, which learns the client's network from an ECS option. A Forwarding Resolver is itself a client of the resolver it queries. It MAY include this option in its own upstream queries, and MUST NOT set a limit larger than the one its client set. Section 7.1.3 of [RFC7871] places the same duty on a Forwarding Resolver using ECS, which must honor the SOURCE PREFIX-LENGTH restrictions in the incoming query from its client. A Forwarding Resolver that constructs the ECS option itself reports to its client the number of address bits it forwards. Where it leaves the ECS option to the resolver it queries, that resolver forwards the Forwarding Resolver's own address. No bits of the client's address reach an authoritative server, and the Forwarding Resolver MUST report 0. Farrokhi & Todd Expires 21 February 2027 [Page 9] Internet-Draft ECS Client Opt-In August 2026 4. Caching A resolver MUST NOT return an answer obtained using ECS to a client that is not a signaling client, and MUST be able to determine, for any cache entry, whether it obtained that entry using ECS. Section 7.3.2 of [RFC7871] matches a lookup from a client that sent no ECS option against that client's own address, which could return a Tailored Response fetched for someone else. Excluding entries obtained using ECS leaves no matching network, and that section then requires the resolver to perform resolution as usual, which it explains is "to avoid Tailored Responses in the cache from being returned to the wrong clients". For signaling clients, the caching and longest-prefix matching rules of Section 7.3 of [RFC7871] apply unchanged. A cache entry whose SOURCE PREFIX-LENGTH is longer than a signaling client's effective prefix length MAY answer that client, because serving it forwards nothing. A client's limit applies only to the address information the resolver forwards and thus does not restrict which cache entry may answer that client. Keeping signaling and non-signaling clients on separate caches implements the rule above, and a resolver that already supports more than one cache needs no new machinery for it. 5. Deviations from RFC 7871 A resolver implementing this document differs from [RFC7871] in four places. 1. It answers a query whose ECS information it does not use, where Section 7.1.1 of [RFC7871] and Section 7.5 of [RFC7871] recommend REFUSED. Section 3.4 states that rule and the precedent Section 7.5 of [RFC7871] sets for it by exempting a query that provides 0 address bits from refusal. 2. It excludes entries obtained using ECS from lookups for clients that did not opt in. Section 4 states that rule, which is stricter than Section 7.3.2 of [RFC7871] and serves the purpose that section gives for its own. 3. It reads the condition that scopes the response requirements of Section 7.2.2 of [RFC7871] per query. Section 3.4 quotes that condition and explains what follows from the reading. Farrokhi & Todd Expires 21 February 2027 [Page 10] Internet-Draft ECS Client Opt-In August 2026 4. It forwards nothing when it receives an unroutable address from a client, where Section 11.3 of [RFC7871] recommends treating that address as the resolver's own identity. This behavior is documented under Section 3.3. Whether these warrant an Updates relationship with [RFC7871] is recorded in Appendix B. 6. Deployment Considerations A resolver that does not implement this option ignores it and answers as it would have anyway, because Section 6.1.2 of [RFC6891] requires that "Any OPTION-CODE values not understood by a responder or requestor MUST be ignored". Clients and resolvers therefore need not be upgraded together. An operator that turns this option on changes what its existing clients receive. A client that sends an ECS option alone no longer has its address information forwarded, and receives untailored answers until it also sends this option. Section 5 of [RFC7871] leaves that choice with the resolver. A client can discover whether a resolver implements this option by sending it and looking at the response, which costs one query and is described in Section 3.3. That is sufficient for most purposes. Such a resolver may still forward the client's address information, including for the query used as a probe. A client probing a resolver it has not used before SHOULD include an ECS option with SOURCE PREFIX-LENGTH 0. Section 7.1.2 of [RFC7871] obliges a resolver that uses ECS to honor that opt-out, and a resolver implementing this option takes the smallest limit present, so neither forwards anything. The response still shows whether the option is supported, and a second query without the ECS option reveals the resolver's own maximum. Where a resolver publishes information about itself using DNS Resolver Information [RFC9606], support for this option would be a natural thing to advertise there. Defining such a key is left to future work, since the response already gives clients an easy way to find out. Farrokhi & Todd Expires 21 February 2027 [Page 11] Internet-Draft ECS Client Opt-In August 2026 7. Security Considerations The value in a response is the resolver's own statement about what it forwarded, and DNSSEC does not protect it, since OPT records are not signed (Section 9 of [RFC7871]). An encrypted transport keeps that value from being altered in transit and does not make it accurate. A resolver can forward more address bits than the client permitted and report a smaller number, which the client can detect only by observing what authoritative servers receive. This option is a request to a resolver that the client has already trusted with every query it sends, and it gives no protection against a resolver that is hostile or compromised. On an unencrypted transport, an on-path attacker can strip this option, add it, or change its value. Stripping it leaves the resolver forwarding nothing. Adding it, or raising the value, forwards address bits the client did not offer. The same attacker can change the value in the response, so a client on an unencrypted transport cannot rely on it. A client that needs its limit respected SHOULD use an encrypted transport such as [RFC7858], [RFC8484], or [RFC9250]. A client that remembers whether a resolver supports this option is trusting a single response, which an on-path attacker can alter or forge. Such a client SHOULD confirm support over an encrypted transport. An attacker can send this option from forged source addresses, which subjects a resolver that would otherwise forward nothing to the cache pollution described in Section 11.3 of [RFC7871]. A resolver that implements this option and serves signaling and non- signaling clients from one cache, without distinguishing the entries obtained using ECS, returns tailored answers to clients that did not opt in, and no field in the response marks an answer as tailored. The requirement in Section 4 is therefore part of implementing this option. 8. Privacy Considerations Under [RFC7871], a client of an ECS-enabled resolver has its address information forwarded unless it opts out. Under this document, a resolver forwards nothing unless the client asks. For a client that opts in, the analysis in Section 11 of [RFC7871] applies unchanged, with one addition that the client can set the limit without supplying an address, as Section 3.4 describes. The forwarded prefix reaches every authoritative server to which the Farrokhi & Todd Expires 21 February 2027 [Page 12] Internet-Draft ECS Client Opt-In August 2026 resolver sends ECS, along with anyone able to observe that traffic. Section 12.1 of [RFC7871] bounds that set, recommending that a resolver omit the option toward nameservers that did not return it and never send it to root, top-level and effective top-level domain servers. A client should set the shortest limit that still yields useful answers, and should not treat a short prefix as anonymous. On an unencrypted transport, anyone on the path can see that a query includes this option, which marks the client as one that implements this document. The one-octet form also reveals the client's limit. Neither identifies a client on its own. 9. IANA Considerations IANA is requested to assign an option code from the "DNS EDNS0 Option Codes (OPT)" registry in the "Domain Name System (DNS) Parameters" registry group. Values in the range 1 to 65000 in that registry are assigned under the Expert Review policy of Section 4.5 of [RFC8126]. That registry also sets a range aside for local and experimental use. This document does not take a value from it. Section 4.2 of [RFC8126] says of such a range that assignments from it "are not generally useful for broad interoperability", and that "Unless the registry explicitly allows it, it is not appropriate for documents to select explicit values from registries or ranges with this policy." An assigned code point can be implemented in released software. +=======+===========================+==========+===============+ | Value | Name | Status | Reference | +=======+===========================+==========+===============+ | TBD | edns-client-subnet-opt-in | Optional | This document | +-------+---------------------------+----------+---------------+ Table 2: EDNS(0) Option Code Requested 10. References 10.1. Normative References [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Farrokhi & Todd Expires 21 February 2027 [Page 13] Internet-Draft ECS Client Opt-In August 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . 10.2. Informative References [RFC7314] Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE Option", RFC 7314, DOI 10.17487/RFC7314, July 2014, . [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, . [RFC9660] Salgado, H., Vergara, M., and D. Wessels, "The DNS Zone Version (ZONEVERSION) Option", RFC 9660, DOI 10.17487/RFC9660, October 2024, . [RFC9606] Reddy.K, T. and M. Boucadair, "DNS Resolver Information", RFC 9606, DOI 10.17487/RFC9606, June 2024, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . Farrokhi & Todd Expires 21 February 2027 [Page 14] Internet-Draft ECS Client Opt-In August 2026 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [I-D.bellis-dnsop-edns-tags] Bellis, R., Clegg, A., and P. van Dijk, "DNS EDNS Tags", Work in Progress, Internet-Draft, draft-bellis-dnsop-edns- tags-01, 25 March 2019, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Appendix A. Alternatives Considered This document defines a new EDNS(0) option code instead of encoding the signal in the ECS option, because every such encoding collides with a rule in [RFC7871]. This appendix records the encodings considered and not adopted. A client can request forwarding and set a limit without supplying an address. The REFUSED guidance in Section 7.1.1 of [RFC7871] and Section 7.5 of [RFC7871], and the requirement in Section 11.2 of [RFC7871] that a response mirror the ECS fields of the query, apply only to a client-supplied address and thus do not cover such a query. * A reserved address used as a sentinel, for example an ECS option containing 127.0.0.1/32 that a resolver would read as an instruction to substitute the source address it observed. A resolver acting on it must either echo the sentinel, which Section 7.5 of [RFC7871] warns yields a response that appears tailored for the network named in the query when it is tailored for another, or echo the address it substituted, which Section 7.3 of [RFC7871] has an Intermediate Nameserver drop because its FAMILY, ADDRESS, and SOURCE PREFIX-LENGTH do not match the query. Farrokhi & Todd Expires 21 February 2027 [Page 15] Internet-Draft ECS Client Opt-In August 2026 That drop is also a cache-poisoning defense, as Section 11.2 of [RFC7871] explains, since an off-path attacker must match those fields for a forged response to be accepted. Handling of such an address is unspecified in any case. Section 11.3 of [RFC7871] recommends that a resolver treat an unroutable address as equivalent to its own identity, and Section 7.5 of [RFC7871] lists private and unroutable address space among the reasons to return REFUSED. At the time of writing, one large public resolver answered a query containing 203.0.113.0/24 with REFUSED while another forwarded the same value to the authoritative server verbatim. * A short ADDRESS field. Section 6 of [RFC7871] requires ADDRESS to hold exactly the octets needed for SOURCE PREFIX-LENGTH bits and recommends FORMERR for a server that receives too few or too many. An empty ADDRESS is valid only with SOURCE PREFIX-LENGTH 0, which already means opt-out. * The SCOPE PREFIX-LENGTH field as an extension point. Section 6 of [RFC7871] requires it to be set to 0 in queries. * A novel FAMILY value. Section 7.1.2 of [RFC7871] notes that "at least one major authoritative server will ignore the option if FAMILY is not 1 or 2", so such a value might degrade quietly, but that behavior is unspecified, and the IANA Address Family Numbers registry is not the place to record a DNS signaling convention. * An EDNS header flag bit. The EDNS Header Flags registry holds few bits and assigns them under Standards Action, which does not fit an experimental client preference. * A bare opt-in with no one-octet form. The zero-length form defined in Section 3.1 serves most clients, but on its own it leaves a client that wants a limit nowhere to put one, because an ECS option requires an address that client may not have, as Section 3.4 describes. * A wider payload with a family selector and a limit per family. A client cannot predict the family it will be seen as coming from, and the extra fields add nothing beyond sending a different value per family. The closest prior art is EDNS-Client-Tag and EDNS-Server-Tag [I-D.bellis-dnsop-edns-tags], an opaque client-to-server signal with a response counterpart, which has the same shape as this design. That work was not completed. Farrokhi & Todd Expires 21 February 2027 [Page 16] Internet-Draft ECS Client Opt-In August 2026 Appendix B. Open Issues This section records decisions that are provisional in this revision. It will be removed before publication. 1. Whether a response to a query that included this option should always include it, as Section 3.3 requires, or should omit it where the resolver forwards nothing. Always including it lets a client tell a resolver that declined from one that does not implement the option, at the cost of one octet in every such response. 2. Whether the reported value should be the effective prefix length, as specified here, or the number of address bits the resolver forwarded while answering that query. The two differ when the answer comes from cache. 3. Whether a malformed option should be treated as absent, as Section 3.3 specifies, or should draw a FORMERR, which [RFC9660] requires for its own option and Section 6 of [RFC7871] recommends for a malformed ECS option. 4. Whether the condition in Section 7.2.2 of [RFC7871], "When an Intermediate Nameserver uses ECS", is read per query or per server. Section 3.4 reads it per query, which lets a resolver answer a query that includes an ECS option without returning one. 5. Whether the differences listed in Section 5 warrant an Updates relationship with [RFC7871]. None of them contradicts a requirement of that document, which is why this revision declares no such relationship. 6. The intended status is Experimental and this revision defines no experiment. A later revision should state what is being evaluated and what would count as success, and should carry an implementation status section as [RFC7942] describes once a reference implementation exists. 7. The registry name requested in the IANA Considerations and the human-readable name of the option are provisional. Authors' Addresses Babak Farrokhi Quad9 Netherlands Email: babak@farrokhi.net Farrokhi & Todd Expires 21 February 2027 [Page 17] Internet-Draft ECS Client Opt-In August 2026 John Todd Quad9 United States of America Email: jtodd@quad9.net Farrokhi & Todd Expires 21 February 2027 [Page 18]