One document matched: draft-ietf-dnsop-edns-client-subnet-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc1700 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1700.xml">
<!ENTITY rfc1918 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2308 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY rfc2663 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY rfc4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4034 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc4193 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY rfc6177 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6177.xml">
<!ENTITY rfc6890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY rfc6891 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY rfc7719 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7719.xml">
]>
<rfc category="info" docName="draft-ietf-dnsop-edns-client-subnet-08"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Client Subnet in DNS Queries</title>
<author fullname="Carlo Contavalli" initials="C." surname="Contavalli">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheater Parkway</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>ccontavalli@google.com</email>
</address>
</author>
<author fullname="Wilmer van der Gaast" initials="W.W."
surname="van der Gaast">
<organization>Google</organization>
<address>
<postal>
<street>Belgrave House, 76 Buckingham Palace Road</street>
<city>London</city>
<code>SW1W 9TQ</code>
<country>UK</country>
</postal>
<email>wilmer@google.com</email>
</address>
</author>
<author fullname="David C Lawrence" initials="D.C." surname="Lawrence">
<organization>Akamai Technologies</organization>
<address>
<postal>
<street>8 Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>
<email>tale@akamai.com</email>
</address>
</author>
<author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>US</country>
</postal>
<email>warren@kumari.net</email>
</address>
</author>
<date year="2016"/>
<area>ops</area>
<workgroup>dnsop</workgroup>
<abstract>
<t>This document describes an EDNS0 extension 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many Authoritative Nameservers today return different responses based
on the perceived topological location of the user. These servers use the
IP address of the incoming query to identify that location. Since most
queries come from intermediate Recursive Resolvers, the source address
is that of the Recursive Resolver rather than of the query
originator.</t>
<t>Traditionally, and probably still in the majority of instances,
Recursive Resolvers are reasonably close in the topological sense to the
Stub Resolvers or Forwarding Resolvers that are the source of queries.
For these resolvers, using their own IP address is sufficient for
Authoritative Nameservers that tailor responses based upon location of
the querier.</t>
<t>Increasingly, though, a class of Recursive Resolvers has arisen that
handle query sources that are often not topologically close. The
motivation for having such Centralized Resolvers varies but is usually
because of some enhanced experience, such as greater cache security or
applying policies regarding where users may connect. (Although political
censorship usually comes to mind here, the same actions may be used by a
parent when setting controls on where a minor may connect.) Similarly,
many ISPs and other organizations use a Centralized Resolver
infrastructure that can be distant from the clients the resolvers serve.
These cases all lead to less than desirable responses from
topology-sensitive Authoritative Nameservers.</t>
<t>This document defines an <xref target="RFC6891">EDNS0</xref> option
to convey network information that is relevant to the DNS message. It
will carry sufficient network information about the originator for the
Authoritative Nameserver to tailor responses. It will also provide for
the Authoritative Nameserver to indicate the scope of network addresses
for which the tailored answer is intended. This EDNS0 option is intended
for those Recursive Resolvers and Authoritative Nameservers that would
benefit from the extension and not for general purpose deployment. It is
completely optional and can safely be ignored by servers that choose not
to implement it or enable it.</t>
<t>This document also includes guidelines on how to best cache those
results and provides recommendations on when this protocol extension
should be used.</t>
<t>At least a dozen different client and server implementations have
been written based on earlier versions of this specification. The
protocol is in active production use today. While the implementations
interoperate, there is varying behavior around edge cases that were
poorly specified. Known incompatibilities are described in this
document, and the authors believe that it is better to describe the
system as it is working today, even if not everyone agrees with the
details of the original specification <xref
target="I-D.vandergaast-edns-client-subnet">(</xref>). The alternative
is an undocumented and proprietary system.</t>
<t>A revised proposal to improve upon the minor flaws in this protocol
will be forthcoming to the IETF.</t>
</section>
<section title="Privacy Note">
<t>If we were just beginning to design this mechanism, and not
documenting existing protocol, it is unlikely that we would have done
things exactly this way.</t>
<t>The IETF is actively working on <xref
target="DPRIVE_Working_Group">enhancing DNS privacy</xref>, and the
re-injection of metadata has been <xref
target="I-D.hardie-privsec-metadata-insertion">identified as a
problematic design pattern</xref></t>
<t>As noted above, however, this document primarily describes existing
behavior of a deployed method, to further the understanding of the
Internet community.</t>
<t>We recommend that the feature be turned off by default in all
nameserver software, and that operators only enable it explicitly in
those circumstances where it provides a clear benefit for their clients.
We also encourage the deployment of means to allow users to make use of
the opt-out provided. Finally, we recommend that others avoid techniques
that may introduce additional metadata in future work, as it may damage
user trust.</t>
<t>Regrettably, support for the opt-out provisions of this specification
are currently limited. Only one stub resolver, getdns, is known to be
able to originate queries with anonymity requested, and as yet no
applications are known to be able to indicate that user preference to
the stub resolver.</t>
</section>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="ECS:">EDNS Client Subnet.</t>
<t hangText="Client:">A Stub Resolver, Forwarding Resolver, or
Recursive Resolver. A client to a Recursive Resolver or a Forwarding
Resolver.</t>
<t hangText="Server:">A Forwarding Resolver, Recursive Resolver or
Authoritative Nameserver.</t>
<t hangText="Stub Resolver:">A simple DNS protocol implementation on
the client side as described in <xref target="RFC1034"/> section
5.3.1. A client to a Recursive Resolver or a Forwarding
Resolver.</t>
<t hangText="Authoritative Nameserver:">A nameserver that has
authority over one or more DNS zones. These are normally not
contacted by Stub Resolver or end user clients directly but by
Recursive Resolvers. Described in <xref target="RFC1035"/> Section
6.</t>
<t hangText="Recursive Resolver:">A nameserver that is responsible
for resolving domain names for clients by following the domain's
delegation chain. Recursive Resolvers frequently use caches to be
able to respond to client queries quickly. Described in <xref
target="RFC1035"/> Section 7.</t>
<t hangText="Forwarding Resolver:">A nameserver that does not do
iterative resolution itself, but instead passes that responsibility
to another Recursive Resolver, called a "Forwarder" in <xref
target="RFC2308"/> section 1.</t>
<t hangText="Intermediate Nameserver:">Any nameserver in between the
Stub Resolver and the Authoritative Nameserver, such as a Recursive
Resolver or a Forwarding Resolver.</t>
<t hangText="Centralized Resolvers:">Intermediate Nameservers that
serve a topologically diverse network address space.</t>
<t hangText="Tailored Response:">A response from a nameserver that
is customized for the node that sent the query, often based on
performance (i.e. lowest latency, least number of hops, topological
distance, ...).</t>
<t hangText="Topologically Close:">Refers to two hosts being close
in terms of number of hops or time it takes for a packet to travel
from one host to the other. The concept of topological distance is
only loosely related to the concept of geographical distance: two
geographically close hosts can still be very distant from a
topological perspective, and two geographically distant hosts can be
quite close on the network.</t>
</list></t>
<t>For a more comprehensive treatment of DNS terms, please see
<xref target="RFC7719"/>.</t>
</section>
<section anchor="overview" title="Overview">
<t>The general idea of this document is to provide an EDNS0 option to
allow Recursive Resolvers, if they are willing, to forward details about
the origin network from which a query is coming when talking to other
Nameservers.</t>
<t>The format of the edns-client-subnet (ECS) EDNS0 option is described
in <xref target="format"/>, and is meant to be added in queries sent by
Intermediate Nameservers in a way transparent to Stub Resolvers and end
users, as described in <xref target="originating"/>. ECS is only defined
for the Internet (IN) DNS class.</t>
<t>As described in <xref target="responding"/>, an Authoritative
Nameserver could use ECS as a hint to the network location of the end
user and provide a better answer. Its response would also contain an ECS
option, clearly indicating that the server made use of this information,
and that the answer is tied to the network of the client.</t>
<t>As described in <xref target="caching"/>, Intermediate Nameservers
would use this information to cache the response.</t>
<t>Some Intermediate Nameservers may also have to be able to forward ECS
queries they receive. This is described in <xref
target="transitivity"/>.</t>
<t>The mechanisms provided by ECS raise various security related
concerns related to cache growth, the ability to spoof EDNS0 options,
and privacy. <xref target="security"/> explores various mitigation
techniques.</t>
<t>The expectation, however, is that this option will primarily be used
between Recursive Resolvers and Authoritative Nameservers that are
sensitive to network location issues. Most Recursive Resolvers,
Authoritative Nameservers and Stub Resolvers will never need to know
about this option, and will continue working as they had been.</t>
<t>Failure to support this option or its improper handling will, at
worst, cause suboptimal identification of client network location, which
is a common occurrence in current content delivery network (CDN)
setups.</t>
<t><xref target="originating"/> also provides a mechanism for Stub
Resolvers to signal Recursive Resolvers that they do not want ECS
treatment for specific queries.</t>
<t>Additionally, operators of Intermediate Nameservers with ECS enabled
are allowed to choose how many bits of the address of received queries
to forward, or to reduce the number of bits forwarded for queries
already including an ECS option.</t>
</section>
<section anchor="format" title="Option Format">
<t>This protocol uses an <xref target="RFC6891">EDNS0</xref>) option to
include client address information in DNS messages. The option is
structured as follows:</t>
<figure>
<artwork align="left"><![CDATA[
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | FAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t><list style="symbols">
<t>(Defined in <xref target="RFC6891"/>) OPTION-CODE, 2 octets, for
ECS is 8 (0x00 0x08).</t>
<t>(Defined in <xref target="RFC6891"/>) OPTION-LENGTH, 2 octets,
contains the length of the payload (everything after OPTION-LENGTH)
in octets.</t>
<t>FAMILY, 2 octets, indicates the family of the address contained
in the option, using address family codes as assigned by IANA in
<xref target="Address_Family_Numbers">Address Family Numbers
</xref>.</t>
</list> The format of the address part depends on the value of FAMILY.
This document only defines the format for FAMILY 1 (IP version 4) and 2
(IP version 6), which are as follows: <list style="symbols">
<t>SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
number of significant bits of ADDRESS to be used for the lookup. In
responses, it mirrors the same value as in the queries.</t>
<t>SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost
number of significant bits of ADDRESS that the response covers. In
queries, it MUST be set to 0.</t>
<t>ADDRESS, variable number of octets, contains either an IPv4 or
IPv6 address, depending on FAMILY, which MUST be truncated to the
number of bits indicated by the SOURCE PREFIX-LENGTH field, padding
with 0 bits to pad to the end of the last octet needed.</t>
<t>A server receiving an ECS option that uses either too few or too
many ADDRESS octets, or that has non-zero ADDRESS bits set beyond
SOURCE PREFIX-LENGTH, SHOULD return FORMERR to reject the packet, as
a signal to the developer of the software making the request to fix
their implementation.</t>
</list> All fields are in network byte order ("big-endian", per <xref
target="RFC1700"/>, Data Notation).</t>
</section>
<section title="Protocol Description">
<section anchor="originating" title="Originating the Option">
<t>The ECS option should generally be added by Recursive Resolvers
when querying Authoritative Nameservers, as described in <xref
target="send_when"/>. The option can also be initialized by a Stub
Resolver or Forwarding Resolver.</t>
<section anchor="originating_recursor" title="Recursive Resolvers">
<t>The setup of the ECS option in a Recursive Resolver depends on
the client query that triggered the resolution process.</t>
<t>In the usual case, where no ECS option was present in the client
query, the Recursive Resolver initializes the option by setting the
FAMILY of the client's address. It then uses the value of its
maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For
privacy reasons, and because the whole IP address is rarely required
to determine a tailored response, this length SHOULD be shorter than
the full address, as described in <xref target="security"/>.</t>
<t>If the triggering query included an ECS option itself, it MUST be
examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's
outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of
the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
cacheable prefix length.</t>
<t>Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the
ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits,
with trailing 0 bits added, if needed, to fill the final octet. The
total number of octets used MUST only be enough to cover SOURCE
PREFIX-LENGTH bits, rather than the full width that would normally
be used by addresses in FAMILY.</t>
<t>FAMILY and ADDRESS information MAY be used from the ECS option in
the incoming query. Passing the existing address data is supportive
of the Recursive Resolver being used as the target of a Forwarding
Resolver, but could possibly run into policy problems with regard to
usage agreements between the Recursive Resolver and Authoritative
Nameserver. See <xref target="whitelist"/> for more discussion on
this point. If the Recursive Resolver will not forward the FAMILY
and ADDRESS data from the incoming ECS option, it SHOULD return a
REFUSED response.</t>
<t>Subsequent queries to refresh the data MUST, if unrestricted by
an incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE
PREFIX-LENGTH that the Recursive Resolver is willing to cache, even
if a previous response indicated that a shorter prefix length was
sufficient.</t>
</section>
<section title="Stub Resolvers" anchor="stubs">
<t>A Stub Resolver MAY generate DNS queries with an ECS option that
sets SOURCE PREFIX-LENGTH to limit how network information should be
revealed. An Intermediate Nameserver that receives such a query MUST
NOT make queries that include more bits of client address than in
the originating query.</t>
<t>A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT
add address information of the client to its queries. The subsequent
Recursive Resolver query to the Authoritative Nameserver will then
either not include an ECS option or MAY optionally include its own
address information, which is what the Authoritative Nameserver will
almost certainly use to generate any Tailored Response in lieu of an
option. This allows the answer to be handled by the same caching
mechanism as other queries, with an explicit indicator of the
applicable scope. Subsequent Stub Resolver queries for /0 can then
be answered from this cached response.</t>
<t>A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include
FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
response if the Intermediate Nameserver that it queries has a policy
that denies forwarding of the ADDRESS. If there is no ADDRESS set,
i.e. SOURCE PREFIX-LENGTH is set to 0, then FAMILY SHOULD be set to
the transport over which the query is sent. This is for
interoperability; at least one major authoritative server will
ignore the option if FAMILY is not 1 or 2, even though it is
irrelevant if there are no ADDRESS bits.</t>
</section>
<section title="Forwarding Resolvers">
<t>Forwarding Resolvers essentially appear to be Stub Resolvers to
whatever Recursive Resolver is ultimately handling the query, but
look like a Recursive Resolver to their client. A Forwarding
Resolver using this option MUST prepare it as described above in
<xref target="originating_recursor"/>, Recursive Resolvers. In
particular, a Forwarding Resolver that implements this protocol MUST
honor SOURCE PREFIX-LENGTH restrictions indicated in the incoming
query from its client. See also <xref target="transitivity"/>.</t>
<t>Since the Recursive Resolver it contacts will treat the
Forwarding Resolver like a Stub Resolver, the Recursive Resolver's
policies regarding incoming ADDRESS information will apply in the
same way. If the Forwarding Resolver receives a REFUSED response
when it sends a query which includes a non-zero ADDRESS, it MUST
retry with no ADDRESS.</t>
</section>
</section>
<section anchor="responding" title="Generating a Response">
<section title="Authoritative Nameserver">
<t>When a query containing an ECS option is received, an
Authoritative Nameserver supporting ECS MAY use the address
information specified in the option in order to generate a tailored
response.</t>
<t>Authoritative Nameservers that have not implemented or enabled
support for the ECS option ought to safely ignore it within incoming
queries, per <xref target="RFC6891"/> section 6.1.2. Such a server
MUST NOT include an ECS option within replies, to indicate lack of
support for it. Implementers of Intermediate Nameservers should be
aware, however, that some nameservers incorrectly echo back unknown
EDNS0 options. In this protocol that should be mostly harmless, as
SCOPE PREFIX-LENGTH should come back as 0, thus marking the response
as covering all networks.</t>
<t>A query with a wrongly formatted option (e.g., an unknown FAMILY)
MUST be rejected and a FORMERR response MUST be returned to the
sender, as described by <xref target="RFC6891"/>, Transport
Considerations.</t>
<t>An Authoritative Nameserver that implements this protocol and
receives an ECS option MUST include an ECS option in its response to
indicate that it SHOULD be cached accordingly, regardless of whether
the client information was needed to formulate an answer. (Note that
the <xref target="RFC6891"/> requirement to reserve space for the
OPT record could mean that the answer section of the response will
be truncated and fallback to TCP indicated accordingly.) If an ECS
option was not included in a query, one MUST NOT be included in the
response even if the server is providing a Tailored Response --
presumably based on the address from which it received the
query.</t>
<t>The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST
match those in the query. Echoing back these values helps to
mitigate certain attack vectors, as described in
<xref target="security"/>.</t>
<t>The SCOPE PREFIX-LENGTH in the response indicates the network for
which the answer is intended.</t>
<t>A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
indicates that the provided prefix length was not specific enough to
select the most appropriate Tailored Response. Future queries for
the name within the specified network SHOULD use the longer SCOPE
PREFIX-LENGTH. Factors affecting whether the Recursive Resolver
would use the longer length include the amount of privacy masking
the operator wants to provide their users, and the additional
resource implications for the cache.</t>
<t>Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more
bits than necessary were provided, and the answer is suitable for a
broader range of addresses. This could be as short as 0, to indicate
that the answer is suitable for all addresses in FAMILY.</t>
<t>As the logical topology of any part of the network with regard to
the tailored response can vary, an Authoritative Nameserver may
return different values of SCOPE PREFIX-LENGTH for different
networks.</t>
<t>Since some queries can result in multiple RRsets being added to
the response, there is an unfortunate ambiguity from the original
specification as to how SCOPE PREFIX-LENGTH would apply to each
individual RRset. For example, multiple types in response to an ANY
metaquery could all have different applicable SCOPE PREFIX-LENGTH
values, but this protocol only has the ability to signal one. The
response SHOULD therefore include the longest relevant PREFIX-LENGTH
of any RRset in the answer, which could have the unfortunate
side-effect of redundantly caching some data that could be cached
more broadly. For the specific case of a CNAME chain, the
Authoritative Nameserver SHOULD only place the initial CNAME record
in the Answer section, to have it cached unambiguously
appropriately. Most modern Recursive Resolvers restart the query
with the canonical name, so the remainder of the chain is typically
ignored anyway. For message-focused resolvers, rather than
RRset-focused ones, this will mean caching the entire CNAME chain at
the longest PREFIX-LENGTH of any RRset in the chain.</t>
<t>The specific logic that an Authoritative Nameserver uses to
choose a tailored response is not in the scope of this document.
Implementers are encouraged, however, to consider carefully their
selection of SCOPE PREFIX-LENGTH for the response in the event that
the best tailored response cannot be determined, and what the
implications would be over the life of the TTL.</t>
<t>Authoritative Nameservers might have situations where one
Tailored Response is appropriate for a relatively broad address
range, such as an IPv4 /20, except for some exceptions, such as a
few /24 ranges within that /20. Because it can't be guaranteed that
queries for all longer prefix lengths would arrive before one that
would be answered by the shorter prefix length, an Authoritative
Nameserver MUST NOT overlap prefixes.</t>
<t>When the Authoritative Nameserver has a longer prefix length
Tailored Response within a shorter prefix length Tailored Response,
then implementations can either:</t>
<t><list style="numbers">
<t>Deaggregate the shorter prefix response into multiple longer
prefix responses, or,</t>
<t>Alert the operator that the order of queries will determine
which answers get cached, and either warn and continue or treat
this as an error and refuse to load the configuration.</t>
</list>This choice should be documented for the operator, for
example in the user manual.</t>
<t>When deaggregating to correct the overlap, prefix lengths should
be optimized to use the minimum necessary to cover the address
space, in order to reduce the overhead that results from having
multipe copies of the same answer. As a trivial example, if the
Tailored Response for 1.2.0/20 is A but there is one exception of
1.2.3/24 for B, then the Authoritative Nameserver would need to
provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and
1.2.8/21 all pointing to A, and 1.2.3/24 to B.</t>
</section>
<section title="Intermediate Nameserver">
<t>When an Intermediate Nameserver uses ECS, whether it passes an
ECS option in its own response to its client is predicated on
whether the client originally included the option. Because a client
that did not use an ECS option might not be able to understand it,
the server MUST NOT provide one in its response. If the client query
did include the option, the server MUST include one in its response,
especially as it could be talking to a Forwarding Resolver which
would need the information for its own caching.</t>
<t>If an Intermediate Nameserver receives a response which has a
longer SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it
provided in its query, it SHOULD still provide the result as the
answer to the triggering client request even if the client is in a
different address range. The Intermediate Nameserver MAY instead opt
to retry with a longer SOURCE PREFIX-LENGTH to get a better reply
before responding to its client, as long as it does not exceed a
SOURCE PREFIX-LENGTH specified in the query that triggered
resolution, but this obviously has implications for the latency of
the overall lookup.</t>
<t>The logic for using the cache to determine whether the
Intermediate Nameserver already knows the response to provide to its
client is covered in the next section.</t>
</section>
</section>
<section anchor="caching" title="Handling ECS Responses and Caching">
<t>When an Intermediate Nameserver receives a response containing an
ECS option and without the TC bit set, it SHOULD cache the result
based on the data in the option. If the TC bit was set, the
Intermediate Resolver SHOULD retry the query over TCP to get the
complete answer section for caching.</t>
<t>If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits
of ADDRESS in the response don't match the non-zero fields in the
corresponding query, the full response MUST be dropped, as described
in <xref target="security"/>. In a response to a query which specified
only the SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and
ADDRESS fields MUST contain the appropriate non-zero information that
the Authoritative Nameserver used to generate the answer, so that it
can be cached accordingly.</t>
<t>If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of this
in <xref target="security"/>.</t>
<t>If a REFUSED response is received from an Authoritative Nameserver,
an ECS-aware resolver MUST retry the query without ECS to distinguish
the response from one where the Authoritative Nameserver is not
responsible for the name, which is a common convention for the REFUSED
status. Similarly, a client of a Recursive Resolver SHOULD retry for
REFUSED because it is not sufficiently clear whether the REFUSED was
because of the ECS option or some other reason.</t>
<section title="Caching the Response">
<t>In the cache, all resource records in the answer section MUST be
tied to the network specified in the response. The appropriate prefix
length depends on the relationship between SOURCE PREFIX-LENGTH,
SCOPE PREFIX-LENGTH, and the maximum cacheable prefix length
configured for the cache.</t>
<t>If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH
store SCOPE PREFIX-LENGTH bits of ADDRESS and mark the response as
valid for all addresses that fall within that range.</t>
<t>Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for
the cache, store SOURCE PREFIX-LENGTH bits of ADDRESS and mark the
response as valid for all addresses that fall within that range.</t>
<t>If SOURCE PREFIX-LENGTH is shorter than the configured maximum
and SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store
SOURCE PREFIX-LENGTH bits of ADDRESS and mark the response as only
valid to answer client queries that specify exactly the same SOURCE
PREFIX-LENGTH in their own ECS option.</t>
<t>The handling of DNSSEC-related records in the answer section was
unspecified in the original draft and inconsistently handled in
existing implementations. An RRSIG must obviously be tied to the
RRset which it signs, but it is RECOMMENDED that all other DNSSEC
records be scoped at /0. See <xref target="dnssec"/> for more.</t>
<t>Note that the additional and authority sections from a DNS
response message are specifically excluded here. Any records from
these sections MUST NOT be tied to a network. See more at <xref
target="otheranswers"/>.</t>
<t>Records that are cached as /0 because of a query's SOURCE
PREFIX-LENGTH of 0 MUST be distinguished from those that are cached
as /0 because of a response's SCOPE PREFIX-LENGTH of 0. The former
should only be used for other /0 queries that the Intermediate
Resolver receives, but the latter is suitable as a response for all
networks.</t>
<t>Although omitting network-specific caching will significantly
simplify an implementation, the resulting drop in cache hits is very
likely to defeat most latency benefits provided by ECS. Therefore,
implementing full caching support as described in this section is
strongly RECOMMENDED.</t>
<t>Enabling support for ECS in an Intermediate Nameserver will
significantly increase the size of the cache, reduce the number of
results that can be served from cache, and increase the load on the
server. Implementing the mitigation techniques described in <xref
target="security"/> is strongly recommended. For cache size issues,
implementers should consider data storage formats that allow the
same answer data to be shared among multiple prefixes.</t>
</section>
<section title="Answering from Cache">
<t>Cache lookups are first done as usual for a DNS query, using the
query tuple of <name, type, class>. Then the appropriate RRset
MUST be chosen based on longest prefix matching. The client address
to use for comparison will depend on whether the Intermediate
Nameserver received an ECS option in its client query.</t>
<t><list style="symbols">
<t>If no ECS option was provided, the client's address is
used.</t>
<t>If there was an ECS option specifying SOURCE PREFIX-LENGTH
and ADDRESS covering the client's address, the client address is
used but SOURCE PREFIX-LENGTH is initially ignored. If no
covering entry is found and SOURCE PREFIX-LENGTH is shorter than
the configured maximum length allowed for the cache, repeat the
cache lookup for an entry that exactly matches SOURCE
PREFIX-LENGTH. These special entries, which do not cover longer
prefix lengths, occur as described in the previous section.</t>
<t>If there was an ECS option with an ADDRESS, the ADDRESS from
it MAY be used if local policy allows. Policy can vary depending
on the agreements the operator of the Intermediate Nameserver
has with Authoritative Nameserver operators; see <xref
target="whitelist"/>. If policy does not allow, a REFUSED
response SHOULD be sent. See <xref target="transitivity"/> for
more.</t>
</list></t>
<t>If a matching network is found and the relevant data is
unexpired, the response is generated as per <xref
target="responding"/>.</t>
<t>If no matching network is found, the Intermediate Nameserver MUST
perform resolution as usual. This is necessary to avoid Tailored
Responses in the cache from being returned to the wrong clients, and
to avoid a single query coming from a client on a different network
from polluting the cache with a Tailored Response for all the users
of that resolver.</t>
</section>
</section>
<section anchor="otheranswers" title="Delegations and Negative Answers">
<t>The prohibition against tying ECS data to records from the
Authority and Additional section left an unfortunate ambiguity in the
original specification, primarily with regard to negative answers. The
expectation of the original authors was that ECS would only really be
used for address requests and the positive result in the response's
answer section, the use case that was driving the definition of the
protocol.</t>
<t>For negative answers, some independent implementations of both
resolvers and authorities did not see the section restriction as
necessarily meaning that a given name and type must only have either
positive ECS-tagged answers or a negative answer. They support being
able to tell one part of the network that the data does not exist,
while telling another part of the network that it does.</t>
<t>Several other implementations, however, do not support being able
to mix positive and negative answers, and thus interoperability is a
problem. It is RECOMMENDED that no specific behavior regarding
negative answers be relied upon, but that Authoritative Nameservers
should conservatively expect that Intermediate Nameservers will treat
all negative answers as /0 and therefore SHOULD set SCOPE
PREFIX-LENGTH accordingly.</t>
<t>This issue is expected to be revisited in a future revision of the
protocol, possibly blessing the mixing of positive and negative
answers. There are implications for cache data structures that
developers should consider when writing new ECS code.</t>
<t>The delegations case is a bit easier to tease out. In operational
practice, if an authoritative server is using address information to
provide customized delegations, it is the resolver that will be using
the answer for its next iterative query. Addresses in the Additional
section SHOULD therefore ignore ECS data, and the Authoritative
Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations. A
recursive resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a
delegation as though it were zero.</t>
</section>
<section anchor="transitivity" title="Transitivity">
<t>Generally, ECS options will only be present in DNS messages between
a Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
In certain configurations however, for example multi-tier nameserver
setups, it may be necessary to implement transitive behavior on
Intermediate Nameservers.</t>
<t>Any Intermediate Nameserver that forwards ECS options received from
its clients MUST fully implement the caching behavior described in
<xref target="caching"/>.</t>
<t>An Intermediate Nameserver MAY forward ECS options with address
information. This information MAY match the source IP address of the
incoming query, and MAY have more or fewer address bits than the
Nameserver would normally include in a locally originated ECS option.
If an Intermediate Nameserver receives a query with SOURCE
PREFIX-LENGTH set to 0 it MUST NOT include client address information
in queries made to resolve that client's request
(see <xref target="stubs"/>).</t>
<t>If for any reason the Intermediate Nameserver does not want to use
the information in an ECS option it receives (too little address
information, network address from a range not authorized to use the
server, private/unroutable address space, etc), it SHOULD drop the
query and return a REFUSED response. Note again that a query MUST NOT
be refused solely because it provides 0 address bits.</t>
<t>Be aware that at least one major existing implementation does not
return REFUSED and instead just processes the query as though the
problematic information were not present. This can lead to anomalous
situations, such as a response from the Intermediate Nameserver that
indicates it is tailored for one network (the one passed in the
original query, since ADDRESS must match) when actually it is for
another network (the one which contains the address that the
Intermediate Nameserver saw as making the query).</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA has already assigned option code 8 in the "DNS EDNS0 Option
Codes (OPT)" registry to ECS.</t>
<t>The IANA is requested to update the reference
("draft-vandergaast-edns-client-subnet") to refer to this RFC when
published.</t>
</section>
<section anchor="dnssec" title="DNSSEC Considerations">
<t>The presence or absence of an <xref target="RFC6891"/> EDNS0 OPT
resource record containing an ECS option in a DNS query does not change
the usage of the resource records and mechanisms used to provide data
origin authentication and data integrity to the DNS, as described in
<xref target="RFC4033"/>, <xref target="RFC4034"/> and <xref
target="RFC4035"/>. OPT records are not signed.</t>
<t>Use of this option, however, does imply increased DNS traffic between
any given Recursive Resolver and Authoritative Nameserver, which could
be another barrier to further DNSSEC adoption in this area.</t>
<t>The initial draft of this protocol, against which several
authoritative and recursive nameserver implementations were written, did
not discuss the handling of DNSSEC RRs and thus it is expected that
there are operational inconsistencies in handling them.</t>
<t>Given the intention of this document to describe how ECS is currently
deployed, specifying new requirements for DNSSEC handling is out of
scope. However, some recommendations can be made as to what is most
likely to result in successful interopration for a DNSSEC-signed ECS
zone, mainly from the point of view of Authoritative Nameservers.</t>
<t>Most DNSSEC records SHOULD be scoped at /0, except for the RRSIG
records which MUST be tied to the RRset that they sign in a Tailored
Response. While it is possible to conceive of a way to get other DNSSEC
records working in a network-specific way, it has little apparent
benefit or likelihood of working with deployed validating resolvers.</t>
<t>One further implication here is that, despite the discussion about
negative answers in <xref target="otheranswers"/>, scoping NSEC or
NSEC3 records at /0 per the previous paragraph necessarily implies that
DNSSEC-signed negative answers must also be network-invariant.</t>
</section>
<section title="NAT Considerations">
<t>Special awareness of ECS in devices that perform Network Address
Translation (NAT) as described in <xref target="RFC2663"/> is not
required; queries can be passed through as-is. The client's network
address SHOULD NOT be added, and existing ECS options, if present,
SHOULD NOT be modified by NAT devices.</t>
<t>In large-scale global networks behind a NAT device (but for example
with Centralized Resolver infrastructure), an internal Intermediate
Nameserver might have detailed network layout information, and may know
which external subnets are used for egress traffic by each internal
network. In such cases, the Intermediate Nameserver MAY use that
information when originating ECS options.</t>
<t>In other cases, if a Recursive Resolver knows it is sited behind a
NAT device, it SHOULD NOT originate ECS options with their external IP
address, and instead rely on downstream Intermediate Nameservers to do
so. It MAY, however, choose to include the option with their internal
address for the purposes of signaling its own limit for SOURCE
PREFIX-LENGTH.</t>
<t>Full treatment of special network addresses is beyond the scope of
this document; handling them will likely differ according to the
operational environments of each service provider. As a general
guideline, if an Authoritative Nameserver on the publicly routed
Internet receives a query that specifies an ADDRESS in <xref
target="RFC1918"/> or <xref target="RFC4193"/> private address space, it
SHOULD ignore ADDRESS and look up its answer based on the address of the
Recursive Resolver. In the response it SHOULD set SCOPE PREFIX-LENGTH to
cover all of the relevant private space. For example, a query for
ADDRESS 10.1.2.0 with a SOURCE PREFIX-LENGTH of 24 would get a returned
SCOPE PREFIX-LENGTH of 8. The Intermediate Nameserver MAY elect to cache
the answer under one entry for <xref target="RFC6890">special-purpose
addresses</xref>; see <xref target="pollution"/>.</t>
</section>
<section anchor="security" title="Security Considerations">
<section title="Privacy">
<t>With the ECS option, the network address of the client that
initiated the resolution becomes visible to all servers involved in
the resolution process. Additionally, it will be visible from any
network traversed by the DNS packets.</t>
<t>To protect users' privacy, Recursive Resolvers are strongly
encouraged to conceal part of the IP address of the user by truncating
IPv4 addresses to 24 bits. 56 bits are recommended for IPv6, based on
<xref target="RFC6177"/>.</t>
<t>ISPs should have more detailed knowledge of their own networks.
That is, they might know that all 24-bit prefixes in a /20 are in the
same area. In those cases, for optimal cache utilization and improved
privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in
this /20 to just 20 bits, instead of 24 as recommended above.</t>
<t>Users who wish their full IP address to be hidden need to configure
their client software, if possible, to include an ECS option
specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). As
described in previous sections, this option will be forwarded across
all the Recursive Resolvers supporting ECS, which MUST NOT modify it
to include the network address of the client.</t>
<t>Note that even without an ECS option, any server queried directly
by the user will be able to see the full client IP address. Recursive
Resolvers or Authoritative Nameservers MAY use the source IP address
of queries to return a cached entry or to generate a Tailored Response
that best matches the query.</t>
</section>
<section title="Birthday Attacks">
<t>ECS adds information to the DNS query tupe (q-tuple). This allows
an attacker to send a caching Intermediate Nameserver multiple queries
with spoofed IP addresses either in the ECS option or as the source
IP. These queries will trigger multiple outgoing queries with the same
name, type and class, just different address information in the ECS
option.</t>
<t>With multiple queries for the same name in flight, the attacker has
a higher chance of success to send a matching response with the SCOPE
PREFIX-LENGTH set to 0 to get it cached for all hosts.</t>
<t>To counter this, the ECS option in a response packet MUST contain
the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the
corresponding query. Intermediate Nameservers processing a response
MUST verify that these match, and SHOULD discard the entire response
if they do not.</t>
<t>That requirement to discard is "SHOULD" instead of "MUST" because
it stands in opposition to the instruction in <xref target="caching"/>
which states that a response lacking an ECS option should be treated
as though it had one of SCOPE PREFIX-LENGTH of 0. If that is always
true, then an attacker does not need to worry about matching the
original ECS option data and just needs to flood back responses that
have no ECS option at all.</t>
<t>This type of attack could be detected in ongoing operations by
marking whether the responding nameserver had previously been sending
ECS option, and/or by taking note of an incoming flood of bogus
responses and flagging the relevant query for re-resolution. This is
more complex than existing nameserver responses to spoof floods, and
would also need to be sensitive to a nameserver legitimately stopping
ECS replies even though it had previously given them.</t>
</section>
<section anchor="pollution" title="Cache Pollution">
<t>It is simple for an arbitrary resolver or client to provide false
information in the ECS option, or to send UDP packets with forged
source IP addresses.</t>
<t>This could be used to: <list style="symbols">
<t>pollute the cache of intermediate resolvers, by filling it with
results that will rarely (if ever) be used.</t>
<t>reverse engineer the algorithms (or data) used by the
Authoritative Nameserver to calculate Tailored Responses.</t>
<t>mount a denial-of-service attack against an Intermediate
Nameserver, by forcing it to perform many more recursive queries
than it would normally do, due to how caching is handled for
queries containing the ECS option.</t>
</list></t>
<t>Even without malicious intent, Centralized Resolvers providing
answers to clients in multiple networks will need to cache different
responses for different networks, putting more memory pressure on the
cache.</t>
<t>To mitigate those problems:</t>
<t><list style="symbols">
<t>Recursive Resolvers implementing ECS should only enable it in
deployments where it is expected to bring clear advantages to the
end users, such as when expecting clients from a variety of
networks or from a wide geographical area. Due to the high cache
pressure introduced by ECS, the feature SHOULD be disabled in all
default configurations.</t>
<t>Recursive Resolvers SHOULD limit the number of networks and
answers they keep in the cache for any given query.</t>
<t>Recursive Resolvers SHOULD limit the number of total different
networks that they keep in cache.</t>
<t>Recursive Resolvers MUST NOT send an ECS option with a SOURCE
PREFIX-LENGTH providing more bits in the ADDRESS than they are
willing to cache responses for.</t>
<t>Recursive Resolvers should implement algorithms to improve the
cache hit rate, given the size constraints indicated above.
Recursive Resolvers MAY, for example, decide to discard more
specific cache entries first.</t>
<t>Authoritative Nameservers and Recursive Resolvers should
discard ECS options that are either obviously forged or otherwise
known to be wrong. They SHOULD at least treat unroutable
addresses, such as some of the address blocks defined in <xref
target="RFC6890"/>, as equivalent to the Recursive Resolver's own
identity. They SHOULD ignore and never forward ECS options
specifying other routable addresses that are known not to be
served by the query source.</t>
<t>The ECS option is just a hint to Authoritative Nameservers for
customizing results. They can decide to ignore the content of the
ECS option based on black or white lists, rate limiting
mechanisms, or any other logic implemented in the software.</t>
</list></t>
</section>
</section>
<section anchor="send_when" title="Sending the Option">
<t>When implementing a Recursive Resolver, there are two strategies on
deciding when to include an ECS option in a query. At this stage, it's
not clear which strategy is best.</t>
<section anchor="probing" title="Probing">
<t>A Recursive Resolver can send the ECS option with every outgoing
query. However, it is RECOMMENDED that Resolvers remember which
Authoritative Nameservers did not return the option with their
response, and omit client address information from subsequent queries
to those Nameservers.</t>
<t>Additionally, Recursive Resolvers SHOULD be configured to never
send the option when querying root, top-level, and effective top-level
(ie, <xref target="Public_Suffix_List">("public suffix")</xref> domain
servers. These domains are delegation-centric and are very unlikely to
generate different responses based on the address of the client.</t>
<t>When probing, it is important that several things are probed:
support for ECS, support for EDNS0, support for EDNS0 options, or
possibly an unreachable Nameserver. Various implementations are known
to drop DNS packets with OPT RRs (with or without options), thus
several probes are required to discover what is supported.</t>
<t>Probing, if implemented, MUST be repeated periodically, e.g.,
daily. If an Authoritative Nameserver indicates ECS support for one
zone, it is to be expected that the Nameserver supports ECS for all of
its zones. Likewise, an Authoritative Nameserver that uses ECS
information for one of its zones, MUST indicate support for the option
in all of its responses to ECS queries. If the option is supported but
not actually used for generating a response, its SCOPE PREFIX-LENGTH
MUST be set to 0.</t>
</section>
<section anchor="whitelist" title="Whitelist">
<t>As described previously, it is expected that only a few Recursive
Resolvers will need to use ECS, and that it will generally be enabled
only if it offers a clear benefit to the users.</t>
<t>To avoid the complexity of implementing a probing and detection
mechanism (and the possible query loss/delay that may come with it),
an implementation could use a whitelist of Authoritative Nameservers
to send the option to, likely specified by their domain name.
Implementations MAY also allow additionally configuring this based on
other criteria, such as zone or query type. As of the time of this
writing, at least one implementation makes use of a whitelist.</t>
<t>An advantage of using a whitelist is that partial client address
information is only disclosed to Nameservers that are known to use the
information, improving privacy.</t>
<t>A drawback is scalability. The operator needs to track which
Authoritative Nameservers support ECS, making it harder for new
Authoritative Nameservers to start using the option.</t>
<t>Similarly, Authoritative Nameservers can also use whitelists to
limit the feature to only certain clients. For example, a CDN that
does not want all of their mapping trivially walked might require a
legal agreement with the Recursive Resolver operator, to clearly
describe the acceptable use of the feature.</t>
<t>The maintenance of access control mechanisms is out of scope for
this protocol definition.</t>
</section>
</section>
<section title="Example">
<t><list style="numbers">
<t>A stub resolver, SR, with IP address
2001:0db8:fd13:4231:2112:8a2e:c37b:7334 tries to resolve
www.example.com by forwarding the query to the Recursive Resolver,
RNS, asking for recursion.</t>
<t>RNS, supporting ECS, looks up www.example.com in its cache. An
entry is found neither for www.example.com, nor for example.com.</t>
<t>RNS builds a query to send to the root and .com servers. The
implementation of RNS provides facilities so an administrator can
configure it not to forward ECS in certain cases. In particular, RNS
is configured to not include an ECS option when talking to TLD or
root nameservers, as described in <xref target="originating"/>.
Thus, no ECS option is added, and resolution is performed as
usual.</t>
<t>RNS now knows the next server to query: the Authoritative
Nameserver, ANS, responsible for example.com.</t>
<t>RNS prepares a new query for www.example.com, including an ECS
option with: <list style="symbols">
<t>OPTION-CODE set to 8.</t>
<t>OPTION-LENGTH set to 0x00 0x0b for the following fixed 4
octets plus the 7 octets that will be used for ADDRESS.</t>
<t>FAMILY set to 0x00 0x02 as IP is an IPv6 address.</t>
<t>SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to
conceal the last 72 bits of every IPv6 address.</t>
<t>SCOPE PREFIX-LENGTH set to 0x00, as specified by this
document for all queries.</t>
<t>ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing
only the first 56 bits of the IPv6 address.</t>
</list></t>
<t>The query is sent. ANS understands and uses ECS. It parses the
ECS option, and generates a Tailored Response.</t>
<t>Due its internal implementation, ANS finds a response that is
tailored for the whole /16 of the client that performed the
query.</t>
<t>ANS adds an ECS option in the response, containing: <list
style="symbols">
<t>OPTION-CODE set to 8.</t>
<t>OPTION-LENGTH set to 0x00 0x07.</t>
<t>FAMILY set to 0x00 0x02.</t>
<t>SOURCE PREFIX-LENGTH set to 0x38, copied from the query.</t>
<t>SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.</t>
<t>ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied
from the query.</t>
</list></t>
<t>RNS receives the response containing an ECS option. It verifies
that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. If
not, the message is discarded.</t>
<t>The response is interpreted as usual. Since the response contains
an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and FAMILY in the
response are used to cache the entry.</t>
<t>RNS sends a response to stub resolver SR, without including an
ECS option.</t>
<t>RNS receives another query to resolve www.example.com. This time,
a response is cached. The response, however, is tied to a particular
network. If the address of the client matches any network in the
cache, then the response is returned from the cache. Otherwise,
another query is performed. If multiple results match, the one with
the longest SCOPE PREFIX-LENGTH is chosen, as per common
best-network match algorithms.</t>
</list></t>
</section>
<section title="Contributing Authors">
<t>The below individuals contributed significantly to the document. The
RFC Editor prefers a maximum of 5 names on the front page, and so we
have listed additional authors in this section</t>
<t><figure>
<artwork><![CDATA[Edward Lewis
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles CA 90094-2536
USA
Email: edward.lewis@icann.org]]></artwork>
</figure></t>
<figure>
<artwork><![CDATA[Sean Leach
Fastly
POBox 78266
San Francisco CA 94107
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Jason Moreau
Akamai Technologies
8 Cambridge Ctr
Cambridge MA 02142-1413
USA
]]></artwork>
</figure>
</section>
<section title="Acknowledgements">
<t>The authors wish to thank Darryl Rodden for his work as a co-author
on previous versions, and the following people for reviewing early
drafts of this document and for providing useful feedback: Paul S. R.
Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, Philip
Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren Kumari, and
Richard Rabbat from Google; Terry Farmer, Mark Teodoro, Edward Lewis,
and Eric Burger from Neustar; David Ulevitch and Matthew Dempsky from
OpenDNS; Patrick W. Gilmore and Steve Hill from Akamai; Colm
MacCarthaigh and Richard Sheehan from Amazon; Tatuya Jinmei from
Infoblox; Andrew Sullivan from Dyn; John Dickinson from Sinodun; Mark
Delany from Apple; Yuri Schaeffer from NLnet Labs; Duane Wessels from
from Verisign; Antonio Querubin; Daniel Kahn Gillmor from the ACLU; Evan
Hunt and Mukund Sivaraman from the Internet Software Consortium; Russ
Housley from Vigilsec; Stephen Farrell from Trinity College Dublin;
Alissa Cooper from Cisco; Suzanne Woolf; and all of the other people
that replied to our emails on various mailing lists.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6890;
&rfc4035;
&rfc4034;
&rfc4033;
&rfc4193;
&rfc6891;
&rfc1035;
&rfc1034;
&rfc1700;
&rfc1918;
&rfc6177;
</references>
<references title="Informative References">
&rfc2308;
&rfc2663;
&rfc7719;
<?rfc include='reference.I-D.hardie-privsec-metadata-insertion'
?>
<?rfc include='reference.I-D.vandergaast-edns-client-subnet'?>
<reference anchor="DPRIVE_Working_Group"
target="https://datatracker.ietf.org/wg/dprive/charter/">
<front>
<title>DPRIVE Working Group</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="Public_Suffix_List"
target="https://publicsuffix.org/">
<front>
<title>Public Suffix List</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="Address_Family_Numbers"
target="http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml">
<front>
<title>Address Family Numbers</title>
<author/>
<date/>
</front>
</reference>
</references>
<section title="Document History">
<t>[RFC Editor: Please delete this section before publication.]</t>
<t>-07 to -08:<list style="symbols">
<t>Jinmei observed that one section saying a /0 "MUST forward the
query as-is" was in conflict with the section that said the option
could be modified to contain the Recursive Resolver address.</t>
<t>Clarify that existing implementations don't interoperate w.r.t
DNSSEC.</t>
<t>Removed vestiges of able to set FAMILY to 0 when specifying just
a SOURCE PREFIX-LENGTH and no ADDRESS. Doesn't interoperate.</t>
<t>Minor wording change in reference to DNS terminology draft.</t>
<t>Change example to use IPv6 per Fred Baker's request.</t>
</list></t>
<t>-06 to -07:<list style="symbols">
<t>Minor comments from Suzanne, Mukund, Jinmei and from the IESG on
the dnsop list.</t>
<t>Incorporated feedback from conference call with Mukund and Evan,
notably clarifying what prefix length to associate with answers in
the cache, how and why to deaggregate, and some DNSSEC stuff.</t>
</list></t>
<t>-05 to -06:<list style="symbols">
<t>Integrated David Lawrence comments.</t>
<t>Ran spellcheck again. One ady I';; laern to tyoe/</t>
</list></t>
<t>-04 to -05:<list style="symbols">
<t>Moved comment about retrying for REFUSED to section on "Handling
ECS Responses". (Jinmei)</t>
<t>Clarify that a new proposal for an improved ECS protool is
expected.</t>
<t>"Forwarders" had been used as though they were the source of a
forwarded query rather than the targeted of one; clarified and
defined as "Forwarding Resolver". (Jinmei)</t>
<t>"representing the leftmost significant bits" => "representing
the leftmost number of significant bits". (Jinmei)</t>
<t>Minor other clarifying text. (Jinmei)</t>
<t>Jinmei's affiliation.</t>
<t>Minor wording clarifications. (David Kahn Gillmor)</t>
<t>Russ Housely's GenART review.</t>
</list></t>
<t>-03 to -04:<list style="symbols">
<t>Privacy note per Ted Hardie’s suggestion.</t>
<t>MUST use minimum octet length to cover PREFIX bits.</t>
<t>Expose note about documenting deployed, if flawed, protocol.</t>
</list></t>
<t>-02 to -03:<list style="symbols">
<t>Some cleanup of the whitelist text.</t>
</list></t>
<t>-01 to -02 (IETF)<list style="symbols">
<t>Clean up the open issues, mostly by saying that they were out of
scope for this document.</t>
<t>How in the world did no reviewers note that "Queries" had been
spelled as "Querys" in the title? (Aaron Falk did.)</t>
</list></t>
<t>-00 to -01 (IETF)<list style="symbols">
<t>Note ambiguity with multiple RRsets appearing in reply, eg, for
an ANY query or CNAME chain. (Duane Wessels)</t>
<t>Open issue questioning the guidance about resolvers behind a NAT.
How do they know they are? What real requirement is this imposing?
(Duane Wessels)</t>
<t>Some other wording changes based on Duane's review of an earlier
draft.</t>
</list></t>
<t>-IND to -00 (IETF)<list style="symbols">
<t><David> Made the document describe how things are actually
implmented now. This makes the document be more of a "this is how we
are doing things, this provides information on that". There may be a
future document that describes additional funcationality.</t>
<t>NETMASK was not a good desription, changed to PREFIX-LENGTH
(Jinmei, others). Stole most of the definition for prefix length
from RFC4291.</t>
<t>Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include
IPv6 (Tatuya Jinmei)</t>
<t>Comment that ECS cannot be used to hand NXDOMAIN to some clients
and not others, primarily because of interoperability issues.
(Tatuya Jinmei)</t>
<t>Added text explaining that implmentations need to document thier
behavior with overlapping networks.</t>
<t>Soften "optimized reply" language. (Andrew Sullivan).</t>
<t>Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0)</t>
<t>Some more grammar / working cleanups.</t>
<t>Replaced a whole heap of occurances of "edns-client-subnet" with
"ECS" for readability. (John Dickinson)</t>
<t>More clearly describe the process from the point of view of each
type of nameserver. (John Dickinson)</t>
<t>Birthday attack still possible if attacker floods with ECS-less
responses. (Yuri Schaeffer)</t>
<t>Added some open issues directly to the text.</t>
</list></t>
<section title="-00">
<t><list style="symbols">
<t>Document moved to experimental track, added experiment
description in header with details in a new section.</t>
<t>Specifically note that ECS applies to the answer section
only.</t>
<t>Warn that caching based on ECS is optional but very important
for performance reasons.</t>
<t>Updated NAT section.</t>
<t>Added recommendation to not use the default /24 recommendation
for the source prefix-length field if more detailed information
about the network is available.</t>
<t>Rewritten problem statement to be more clear about the goal of
ECS and the fact that it's entirely optional.</t>
<t>Wire format changed to include the original address and prefix
length in responses in defence against birthday attacks.</t>
<t>Security considerations now includes a section about birthday
attacks.</t>
<t>Renamed edns-client-ip in ECS, following suggestions on the
mailing list.</t>
<t>Clarified behavior of resolvers when presented with an invalid
ECS option.</t>
<t>Fully take multi-tier DNS setups in mind and be more clear
about where the option should be originated.</t>
<t>A note on Authoritative Nameservers receiving queries that
specify private address space.</t>
<t>A note to always ask for the longest acceptable SOURCE prefix
length, even if a prior answer indicated that a shorter prefix
length was suitable.</t>
<t>Marked up a few more references.</t>
<t>Added a few definitions in the Terminology section, and a few
more aesthetic changes in the rest of the document.</t>
</list></t>
</section>
<section title="-01">
<t><list style="symbols">
<t>Document version number reset from -02 to -00 due to the rename
of base document.</t>
<t>Clarified example (dealing with TLDs, and various minor
errors).</t>
<t>Referencing RFC5035 instead of RFC1918.</t>
<t>Added a section on probing (and how it should be done) vs.
whitelisting.</t>
<t>Moved description on how to forward ECS option in dedicated
section.</t>
<t>Queries with wrongly formatted ECS options should now be
rejected with FORMERR.</t>
<t>Added an "Overview" section, providing an introduction to the
document.</t>
<t>Intermediate Nameservers can now remove an ECS option, or
reduce the SOURCE PREFIX-LENGTH to increase privacy.</t>
<t>Added a reference to DoS attacks in the Security section.</t>
<t>Don't use "network range", as it seems to have different
meaning in other contexts, and turned out to be confusing.</t>
<t>Use shorter and longer prefix lengths, rather than higher or
lower. Add a better explanation in the format section.</t>
<t>Minor corrections in various other sections.</t>
</list></t>
</section>
<section title="-02">
<t><list style="symbols">
<t>Added IANA-assigned option code.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:57 |