Client Opt-In Signaling for EDNS Client Subnet
draft-farrokhi-dnsop-ecs-opt-in-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Babak Farrokhi , John Todd | ||
| Last updated | 2026-08-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-farrokhi-dnsop-ecs-opt-in-00
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,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
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, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
10.2. Informative References
[RFC7314] Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE
Option", RFC 7314, DOI 10.17487/RFC7314, July 2014,
<https://www.rfc-editor.org/info/rfc7314>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<https://www.rfc-editor.org/info/rfc7828>.
[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,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC9660] Salgado, H., Vergara, M., and D. Wessels, "The DNS Zone
Version (ZONEVERSION) Option", RFC 9660,
DOI 10.17487/RFC9660, October 2024,
<https://www.rfc-editor.org/info/rfc9660>.
[RFC9606] Reddy.K, T. and M. Boucadair, "DNS Resolver Information",
RFC 9606, DOI 10.17487/RFC9606, June 2024,
<https://www.rfc-editor.org/info/rfc9606>.
[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, <https://www.rfc-editor.org/info/rfc7858>.
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,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[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,
<https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-
edns-tags-01>.
[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,
<https://www.rfc-editor.org/info/rfc7942>.
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]