]> Quad9

Netherlands babak@farrokhi.net

Quad9

United States of America jtodd@quad9.net

Internet DNS EDNS ECS EDNS Client Subnet privacy opt-in 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.

Introduction EDNS Client Subnet 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 obliges the recursive resolver to honor. That client can also ask for a shorter prefix, but 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.

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 differently, which lists.

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 when, and only when, they appear in all capitals, as shown here. DNS terminology follows BCP 219 . ECS terminology follows and is not redefined here. This includes SOURCE PREFIX-LENGTH, SCOPE PREFIX-LENGTH, Tailored Response, Intermediate Nameserver, and Forwarding Resolver, none of which 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 is nonzero.

The ECS Opt-In Option

Option Format This document specifies a new EDNS(0) 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. and likewise define options whose length differs between queries and responses. OPTION-DATA, where present, is a single field:

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 , 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.

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 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. 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. specifies how the two options interact. A client SHOULD NOT supply a private address in an ECS option, because 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 , and answers as it would have anyway. covers how much a client can trust the reported value.

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 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. 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 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,
• 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. 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. 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 defines, or a routable address the query source is known not to serve. 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 . 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 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 , 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 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

This departs from the usual handling of a malformed EDNS option. recommends FORMERR for a malformed ECS option, and and 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.

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 , 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 do not apply, as 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 requires of a resolver that uses ECS. Its FAMILY, ADDRESS and SOURCE PREFIX-LENGTH are those of the query, which 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.

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. 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 recommends against forwarding such an address and 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 specifies. A larger value in this option cannot raise the ECS limit, because 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 requires. A Forwarding Resolver may add an ECS option for the clients it serves, as describes, so an ECS option says nothing about what the client that sent the query wants. A resolver never forwards this option (), so only that client can have added it. and 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. already makes an exception of this kind, noting "that a query MUST NOT be refused solely because it provides 0 address bits". 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 forwards nothing in any of these cases. Address Bits Forwarded for Each Combination of Options

Query includes	Bits of the client's address forwarded
neither option	none
an ECS option only	none
this option, zero-length	the resolver's maximum
this option, one octet N	the smallest of N and the resolver's maximum
both options	the smallest of all limits present

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. describes EDNS as a hop-by-hop extension, negotiated between each pair of hosts in the resolution process, and 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. 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.

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. 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 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.

Deviations from RFC 7871 A resolver implementing this document differs from in four places.

1. It answers a query whose ECS information it does not use, where and recommend REFUSED. states that rule and the precedent 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. states that rule, which is stricter than and serves the purpose that section gives for its own.
3. It reads the condition that scopes the response requirements of per query. quotes that condition and explains what follows from the reading.
4. It forwards nothing when it receives an unroutable address from a client, where recommends treating that address as the resolver's own identity. This behavior is documented under .

Whether these warrant an Updates relationship with is recorded in .

Deployment Considerations A resolver that does not implement this option ignores it and answers as it would have anyway, because 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. 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 . 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. 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 , 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.

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 (). 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 , , or . 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 . 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 is therefore part of implementing this option.

Privacy Considerations Under , 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 applies unchanged, with one addition that the client can set the limit without supplying an address, as describes. The forwarded prefix reaches every authoritative server to which the resolver sends ECS, along with anyone able to observe that traffic. 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.

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 . That registry also sets a range aside for local and experimental use. This document does not take a value from it. 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. EDNS(0) Option Code Requested

Value	Name	Status	Reference
TBD	edns-client-subnet-opt-in	Optional	This document

References Normative References This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. Informative References This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries. DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The SERIAL field from the Start of Authority (SOA) resource record (RR) is a good example of a zone's version, and it is the only one defined by this specification. Additional version types may be defined by future specifications. Including zone version data in a response simplifies and improves the quality of debugging and diagnostics since the version and the DNS answer are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the DNS Name Server Identifier (NSID) option described in RFC 5001. This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such information is beyond the scope of this document. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Internet Systems Consortium, Inc. Internet Systems Consortium, Inc. PowerDNS.COM B.V. This document describes EDNS Tags, a mechanism by which DNS clients and servers can transmit an opaque data field which has no defined semantic meaning other than as previously agreed between the client and server. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

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 . 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 and , and the requirement in 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 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 has an Intermediate Nameserver drop because its FAMILY, ADDRESS, and SOURCE PREFIX-LENGTH do not match the query. That drop is also a cache-poisoning defense, as 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. recommends that a resolver treat an unroutable address as equivalent to its own identity, and 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. 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. requires it to be set to 0 in queries.
• A novel FAMILY value. 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 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 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 , an opaque client-to-server signal with a response counterpart, which has the same shape as this design. That work was not completed.

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 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 specifies, or should draw a FORMERR, which requires for its own option and recommends for a malformed ECS option.
4. Whether the condition in , "When an Intermediate Nameserver uses ECS", is read per query or per server. 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 warrant an Updates relationship with . 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 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.