< draft-ietf-dnsop-edns-client-subnet-06.txt   draft-ietf-dnsop-edns-client-subnet-07.txt >
dnsop C. Contavalli dnsop C. Contavalli
Internet-Draft W. van der Gaast Internet-Draft W. van der Gaast
Intended status: Informational Google Intended status: Informational Google
Expires: June 17, 2016 D. Lawrence Expires: September 22, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
December 15, 2015 March 21, 2016
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-06 draft-ietf-dnsop-edns-client-subnet-07
Abstract Abstract
This document defines an EDNS0 extension to carry information about This document describes an EDNS0 extension that is in active use to
the network that originated a DNS query, and the network for which carry information about the network that originated a DNS query, and
the subsequent response can be cached. 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 17, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8
7.1. Originating the Option . . . . . . . . . . . . . . . . . 8 7.1. Originating the Option . . . . . . . . . . . . . . . . . 8
7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8
7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9
7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 9 7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 9
7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10
7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10
7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12
7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 13
7.3.1. Caching the Response . . . . . . . . . . . . . . . . 13 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 13
7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 14
7.4. Delegations and Negative Answers . . . . . . . . . . . . 14 7.4. Delegations and Negative Answers . . . . . . . . . . . . 15
7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 16 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 17
10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 17 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 19
11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 18 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 20
12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 19 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 21
12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 20 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 22
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
16.1. Normative References . . . . . . . . . . . . . . . . . . 23 16.1. Normative References . . . . . . . . . . . . . . . . . . 25
16.2. Informative References . . . . . . . . . . . . . . . . . 24 16.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Document History . . . . . . . . . . . . . . . . . . 25 Appendix A. Document History . . . . . . . . . . . . . . . . . . 27
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Many Authoritative Nameservers today return different responses based Many Authoritative Nameservers today return different responses based
on the perceived topological location of the user. These servers use on the perceived topological location of the user. These servers use
the IP address of the incoming query to identify that location. the IP address of the incoming query to identify that location.
Since most queries come from intermediate Recursive Resolvers, the Since most queries come from intermediate Recursive Resolvers, the
source address is that of the Recursive Resolver rather than of the source address is that of the Recursive Resolver rather than of the
query originator. query originator.
Traditionally, and probably still in the majority of instances, Traditionally, and probably still in the majority of instances,
Recursive Resolvers are reasonably close in the topological sense to Recursive Resolvers are reasonably close in the topological sense to
the Stub Resolvers or Forwarding Resolvers that are the source of the Stub Resolvers or Forwarding Resolvers that are the source of
queries. For these resolvers, using their own IP address is queries. For these resolvers, using their own IP address is
sufficient for authority servers that tailor responses based upon sufficient for Authoritative Nameservers that tailor responses based
location of the querier. upon location of the querier.
Increasingly, though, a class of Recursive Resolvers has arisen that Increasingly, though, a class of Recursive Resolvers has arisen that
handle query sources that are often not topologically close. The handle query sources that are often not topologically close. The
motivation for a user to configure such a Centralized Resolver varies motivation for having such Centralized Resolvers varies but is
but is usually because of some enhanced experience, such as greater usually because of some enhanced experience, such as greater cache
cache security or applying policies regarding where users may security or applying policies regarding where users may connect.
connect. (Although political censorship usually comes to mind here, (Although political censorship usually comes to mind here, the same
the same actions may be used by a parent when setting controls on actions may be used by a parent when setting controls on where a
where a minor may connect.) Similarly, many ISPs and other minor may connect.) Similarly, many ISPs and other organizations use
organizations use a Centralized Resolver infrastructure that can be a Centralized Resolver infrastructure that can be distant from the
distant from the clients the resolvers serve. These cases all lead clients the resolvers serve. These cases all lead to less than
to less than desirable responses from topology-sensitive desirable responses from topology-sensitive Authoritative
Authoritative Nameservers. Nameservers.
This document defines an EDNS0 [RFC6891] option to convey network This document defines an EDNS0 [RFC6891] option to convey network
information that is relevant to the DNS message. It will carry information that is relevant to the DNS message. It will carry
sufficient network information about the originator for the sufficient network information about the originator for the
Authoritative Nameserver to tailor responses. It will also provide Authoritative Nameserver to tailor responses. It will also provide
for the Authoritative Nameserver to indicate the scope of network for the Authoritative Nameserver to indicate the scope of network
addresses for which the tailored answer is intended. This EDNS0 addresses for which the tailored answer is intended. This EDNS0
option is intended for those recursive and authority servers that option is intended for those Recursive Resolvers and Authoritative
would benefit from the extension and not for general purpose Nameservers that would benefit from the extension and not for general
deployment. It is completely optional and can safely be ignored by purpose deployment. It is completely optional and can safely be
servers that choose not to implement it or enable it. ignored by servers that choose not to implement it or enable it.
This document also includes guidelines on how to best cache those This document also includes guidelines on how to best cache those
results and provides recommendations on when this protocol extension results and provides recommendations on when this protocol extension
should be used. should be used.
At least a dozen different client and server implementations have At least a dozen different client and server implementations have
been written based on earlier versions of this specification. The been written based on earlier versions of this specification. The
protocol is in active production use today. While the protocol is in active production use today. While the
implementations interoperate, there is varying behavior around edge implementations interoperate, there is varying behavior around edge
cases that were poorly specified. Known incompatibilities are cases that were poorly specified. Known incompatibilities are
skipping to change at page 4, line 29 skipping to change at page 4, line 29
The IETF is actively working on enhancing DNS privacy The IETF is actively working on enhancing DNS privacy
[DPRIVE_Working_Group], and the re-injection of metadata has been [DPRIVE_Working_Group], and the re-injection of metadata has been
identified as a problematic design pattern identified as a problematic design pattern
[I-D.hardie-privsec-metadata-insertion] [I-D.hardie-privsec-metadata-insertion]
As noted above, however, this document primarily describes existing As noted above, however, this document primarily describes existing
behavior of a deployed method, to further the understanding of the behavior of a deployed method, to further the understanding of the
Internet community. Internet community.
We encourage the deployment of means to allow users to make use of We recommend that the feature be turned off by default in all
the opt-out provided. We also recommend that others avoid techniques nameserver software, and that operators only enable it explicitly in
that may introduce additional metadata in future work, as it may those circumstances where it provides a clear benefit for their
damage user trust. 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.
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.
3. Requirements Notation 3. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Terminology 4. Terminology
ECS: EDNS Client Subnet. ECS: EDNS Client Subnet.
skipping to change at page 5, line 44 skipping to change at page 6, line 5
lowest latency, least number of hops, topological distance, ...). lowest latency, least number of hops, topological distance, ...).
Topologically Close: Refers to two hosts being close in terms of 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 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 host to the other. The concept of topological distance is only
loosely related to the concept of geographical distance: two loosely related to the concept of geographical distance: two
geographically close hosts can still be very distant from a geographically close hosts can still be very distant from a
topological perspective, and two geographically distant hosts can topological perspective, and two geographically distant hosts can
be quite close on the network. be quite close on the network.
For a more comprehensive treatment of these DNS terms, please see
[RFC7719].
5. Overview 5. Overview
The general idea of this document is to provide an EDNS0 option to The general idea of this document is to provide an EDNS0 option to
allow Recursive Resolvers, if they are willing, to forward details allow Recursive Resolvers, if they are willing, to forward details
about the origin network from which a query is coming when talking to about the origin network from which a query is coming when talking to
other Nameservers. other Nameservers.
The format of this option is described in Section 6, and is meant to The format of the edns-client-subnet (ECS) EDNS0 option is described
be added in queries sent by Intermediate Nameservers in a way in Section 6, and is meant to be added in queries sent by
transparent to Stub Resolvers and end users, as described in Intermediate Nameservers in a way transparent to Stub Resolvers and
Section 7.1. ECS is only defined for the Internet (IN) DNS class. end users, as described in Section 7.1. ECS is only defined for the
Internet (IN) DNS class.
As described in Section 7.2, an Authoritative Nameserver could use As described in Section 7.2, an Authoritative Nameserver could use
this EDNS0 option as a hint to better locate the network of the end ECS as a hint to the network location of the end user and provide a
user and provide a better answer. better answer. Its response would also contain an ECS option,
Its response would contain an edns-client-subnet (ECS) option,
clearly indicating that the server made use of this information, and clearly indicating that the server made use of this information, and
that the answer is tied to the network of the client. that the answer is tied to the network of the client.
As described in Section 7.3, Intermediate Nameservers would use this As described in Section 7.3, Intermediate Nameservers would use this
information to cache the response. information to cache the response.
Some Intermediate Nameservers may also have to be able to forward ECS Some Intermediate Nameservers may also have to be able to forward ECS
queries they receive. This is described in Section 7.5. queries they receive. This is described in Section 7.5.
The mechanisms provided by ECS raise various security related The mechanisms provided by ECS raise various security related
concerns related to cache growth, the ability to spoof EDNS0 options, concerns related to cache growth, the ability to spoof EDNS0 options,
and privacy. Section 11 explores various mitigation techniques. and privacy. Section 11 explores various mitigation techniques.
The expectation, however, is that this option will primarily be used The expectation, however, is that this option will primarily be used
between Recursive Resolvers and Authoritative Nameservers that are between Recursive Resolvers and Authoritative Nameservers that are
sensitive to network location issues. Most Recursive Resolvers, sensitive to network location issues. Most Recursive Resolvers,
Authoritative Nameservers and Stub Resolvers will never need to know Authoritative Nameservers and Stub Resolvers will never need to know
about this option, and will continue working as they had been. about this option, and will continue working as they had been.
Failure to support this option or its improper handling will, at Failure to support this option or its improper handling will, at
worst, cause suboptimal identification of client location, which is a worst, cause suboptimal identification of client network location,
common occurrence in current content delivery network (CDN) setups. which is a common occurrence in current content delivery network
(CDN) setups.
Section 7.1 also provides a mechanism for Stub Resolvers to signal Section 7.1 also provides a mechanism for Stub Resolvers to signal
Recursive Resolvers that they do not want ECS treatment for specific Recursive Resolvers that they do not want ECS treatment for specific
queries. queries.
Additionally, operators of Intermediate Nameservers with ECS enabled Additionally, operators of Intermediate Nameservers with ECS enabled
are allowed to choose how many bits of the address of received 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 to forward, or to reduce the number of bits forwarded for
queries already including an ECS option. queries already including an ECS option.
skipping to change at page 7, line 45 skipping to change at page 8, line 7
o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost
number of significant bits of ADDRESS that the response covers. number of significant bits of ADDRESS that the response covers.
In queries, it MUST be set to 0. In queries, it MUST be set to 0.
o ADDRESS, variable number of octets, contains either an IPv4 or o ADDRESS, variable number of octets, contains either an IPv4 or
IPv6 address, depending on FAMILY, which MUST be truncated to the IPv6 address, depending on FAMILY, which MUST be truncated to the
number of bits indicated by the SOURCE PREFIX-LENGTH field, number of bits indicated by the SOURCE PREFIX-LENGTH field,
padding with 0 bits to pad to the end of the last octet needed. padding with 0 bits to pad to the end of the last octet needed.
o A server receiving an ECS option that uses more ADDRESS octets o A server receiving an ECS option that uses either too few or too
than are needed, or that has non-zero bits set beyond SOURCE many ADDRESS octets, or that has non-zero ADDRESS bits set beyond
PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a SOURCE PREFIX-LENGTH, SHOULD return FORMERR to reject the packet,
signal to the developer of the software making the request to fix as a signal to the developer of the software making the request to
their implementation. fix their implementation.
All fields are in network byte order ("big-endian", per [RFC1700], All fields are in network byte order ("big-endian", per [RFC1700],
Data Notation). Data Notation).
7. Protocol Description 7. Protocol Description
7.1. Originating the Option 7.1. Originating the Option
The ECS option should generally be added by Recursive Resolvers when The ECS option should generally be added by Recursive Resolvers when
querying Authoritative Nameservers, as described in Section 12. The querying Authoritative Nameservers, as described in Section 12. The
skipping to change at page 9, line 9 skipping to change at page 9, line 22
from the incoming ECS option, it SHOULD return a REFUSED response. from the incoming ECS option, it SHOULD return a REFUSED response.
Subsequent queries to refresh the data MUST, if unrestricted by an Subsequent queries to refresh the data MUST, if unrestricted by an
incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
LENGTH that the Recursive Resolver is willing to cache, even if a LENGTH that the Recursive Resolver is willing to cache, even if a
previous response indicated that a shorter prefix length was previous response indicated that a shorter prefix length was
sufficient. sufficient.
7.1.2. Stub Resolvers 7.1.2. Stub Resolvers
A Stub Resolver MAY generate DNS queries with an ECS option set to A Stub Resolver MAY generate DNS queries with an ECS option that sets
indicate its own level of privacy via SOURCE PREFIX-LENGTH. An SOURCE PREFIX-LENGTH to limit how network information should be
Intermediate Nameserver that receives such a query MUST NOT make revealed. An Intermediate Nameserver that receives such a query MUST
queries that include more bits of client address than in the NOT make queries that include more bits of client address than in the
originating query. originating query.
A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add
address information of the client to its queries. The subsequent address information of the client to its queries. The subsequent
Recursive Resolver query to the Authoritative Nameserver will then Recursive Resolver query to the Authoritative Nameserver will then
either not include an ECS option or MAY optionally include its own either not include an ECS option or MAY optionally include its own
address information, which is what the Authoritative Nameserver will address information, which is what the Authoritative Nameserver will
almost certainly use to generate any Tailored Response in lieu of an almost certainly use to generate any Tailored Response in lieu of an
option. This allows the answer to be handled by the same caching option. This allows the answer to be handled by the same caching
mechanism as other queries, with an explicit indicator of the mechanism as other queries, with an explicit indicator of the
applicable scope. Subsequent Stub Resolver queries for /0 can then applicable scope. Subsequent Stub Resolver queries for /0 can then
be answered from this cached response. be answered from this cached response.
A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include 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 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
response if the Intermediate Nameserver that it queries has a policy response if the Intermediate Nameserver that it queries has a policy
that denies forwarding of the ADDRESS. If there is no ADDRESS set, that denies forwarding of the ADDRESS. If there is no ADDRESS set,
i.e. SOURCE PREFIX-LENGTH is set to 0, FAMILY MUST be set to 0. i.e. SOURCE PREFIX-LENGTH is set to 0, then FAMILY MUST be set to 0.
7.1.3. Forwarding Resolvers 7.1.3. Forwarding Resolvers
Forwarding Resolvers essentially appear to be Stub Resolvers to Forwarding Resolvers essentially appear to be Stub Resolvers to
whatever Recursive Resolver is ultimately handling the query, but whatever Recursive Resolver is ultimately handling the query, but
look like a Recursive Resolver to their client. A Forwarding look like a Recursive Resolver to their client. A Forwarding
Resolver using this option MUST prepare it as described in the Resolver using this option MUST prepare it as described above in
Section 7.1.1 section above. In particular, a Forwarding Resolver Section 7.1.1, Recursive Resolvers. In particular, a Forwarding
that implements this protocol MUST honor SOURCE PREFIX-LENGTH Resolver that implements this protocol MUST honor SOURCE PREFIX-
restrictions indicated in the incoming query from its client. See LENGTH restrictions indicated in the incoming query from its client.
also Section 7.5. See also Section 7.5.
Since the Recursive Resolver it contacts will treat it like a Stub Since the Recursive Resolver it contacts will treat the Forwarding
Resolver, the Recursive Resolver's policies regarding incoming Resolver like a Stub Resolver, the Recursive Resolver's policies
ADDRESS information will apply in the same way. If the Forwarding regarding incoming ADDRESS information will apply in the same way.
Resolver receives a REFUSED response when it sends a query which If the Forwarding Resolver receives a REFUSED response when it sends
includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS a query which includes a non-zero ADDRESS, it MUST retry with FAMILY
set to 0. set to 0 and no ADDRESS.
7.2. Generating a Response 7.2. Generating a Response
7.2.1. Authoritative Nameserver 7.2.1. Authoritative Nameserver
When a query containing an ECS option is received, an Authoritative When a query containing an ECS option is received, an Authoritative
Nameserver supporting ECS MAY use the address information specified Nameserver supporting ECS MAY use the address information specified
in the option in order to generate a tailored response. in the option in order to generate a tailored response.
Authoritative Nameservers that have not implemented or enabled Authoritative Nameservers that have not implemented or enabled
skipping to change at page 10, line 40 skipping to change at page 10, line 49
the client information was needed to formulate an answer. (Note that the client information was needed to formulate an answer. (Note that
the [RFC6891] requirement to reserve space for the OPT record could the [RFC6891] requirement to reserve space for the OPT record could
mean that the answer section of the response will be truncated and mean that the answer section of the response will be truncated and
fallback to TCP indicated accordingly.) If an ECS option was not 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 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 server is providing a Tailored Response -- presumably based on
the address from which it received the query. the address from which it received the query.
The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST
match those in the query, unless the query specified only the SOURCE match those in the query, unless the query specified only the SOURCE
PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0). PREFIX-LENGTH for privacy (and thus with FAMILY set to 0 and no
Echoing back these values helps to mitigate certain attack vectors, ADDRESS). Echoing back these values helps to mitigate certain attack
as described in Section 11. vectors, as described in Section 11.
The SCOPE PREFIX-LENGTH in the response indicates the network for The SCOPE PREFIX-LENGTH in the response indicates the network for
which the answer is intended. which the answer is intended.
A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
indicates that the provided prefix length was not specific enough to indicates that the provided prefix length was not specific enough to
select the most appropriate Tailored Response. Future queries for select the most appropriate Tailored Response. Future queries for
the name within the specified network SHOULD use the longer SCOPE the name within the specified network SHOULD use the longer SCOPE
PREFIX-LENGTH. 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.
Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits
than necessary were provided, and the answer is suitable for a than necessary were provided, and the answer is suitable for a
broader range of addresses. This could be as short as 0, to indicate broader range of addresses. This could be as short as 0, to indicate
that the answer is suitable for all addresses in FAMILY. that the answer is suitable for all addresses in FAMILY.
As the logical topology of any part of the network with regard to the As the logical topology of any part of the network with regard to the
tailored response can vary, an Authoritative Nameserver may return tailored response can vary, an Authoritative Nameserver may return
different values of SCOPE PREFIX-LENGTH for different networks. different values of SCOPE PREFIX-LENGTH for different networks.
Since some queries can result in multiple RRsets being added to the Since some queries can result in multiple RRsets being added to the
response, there is an unfortunate ambiguity from the original response, there is an unfortunate ambiguity from the original
specification as to how SCOPE PREFIX-LENGTH would apply to each specification as to how SCOPE PREFIX-LENGTH would apply to each
individual RRset. For example, multiple types in response to an ANY individual RRset. For example, multiple types in response to an ANY
metaquery could all have different applicable SCOPE PREFIX-LENGTH metaquery could all have different applicable SCOPE PREFIX-LENGTH
values, but this protocol only has the ability to signal one. The values, but this protocol only has the ability to signal one. The
response SHOULD therefore include the longest relevant PREFIX-LENGTH response SHOULD therefore include the longest relevant PREFIX-LENGTH
of any RRset in the answer, which could have the unfortunate side- of any RRset in the answer, which could have the unfortunate side-
effect of redundantly caching some data that could be cached more effect of redundantly caching some data that could be cached more
broadly. For the specific case of a CNAME chain, the Authoritative broadly. For the specific case of a CNAME chain, the Authoritative
Nameserver SHOULD only place the CNAME to have it cached Nameserver SHOULD only place the initial CNAME record in the Answer
unambiguously appropriately. Most modern Recursive Resolvers restart section, to have it cached unambiguously appropriately. Most modern
the query with the canonical name, so the remainder of the chain is Recursive Resolvers restart the query with the canonical name, so the
typically ignored anyway. For message-focused resolvers, rather than remainder of the chain is typically ignored anyway. For message-
RRset-focused ones, this will mean caching the entire CNAME chain at focused resolvers, rather than RRset-focused ones, this will mean
the longest PREFIX-LENGTH of any RRset in the chain. caching the entire CNAME chain at the longest PREFIX-LENGTH of any
RRset in the chain.
The specific logic that an Authoritative Nameserver uses to choose a The specific logic that an Authoritative Nameserver uses to choose a
tailored response is not in the scope of this document. Implementers tailored response is not in the scope of this document. Implementers
are encouraged, however, to consider carefully their selection of are encouraged, however, to consider carefully their selection of
SCOPE PREFIX-LENGTH for the response in the event that the best SCOPE PREFIX-LENGTH for the response in the event that the best
tailored response cannot be determined, and what the implications tailored response cannot be determined, and what the implications
would be over the life of the TTL. would be over the life of the TTL.
If the Authoritative Nameserver operator configures a more specific Authoritative Nameservers might have situations where one Tailored
(longer prefix length) Tailored Response within a configured less Response is appropriate for a relatively broad address range, such as
specific (shorter prefix length) Tailored Response, then 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.
When the Authoritative Nameserver has a longer prefix length Tailored
Response within a shorter prefix length Tailored Response, then
implementations can either: implementations can either:
1. Deaggregate the shorter prefix response into multiple longer 1. Deaggregate the shorter prefix response into multiple longer
prefix responses, or, prefix responses, or,
2. Alert the operator that the order of queries will determine which 2. Alert the operator that the order of queries will determine which
answers get cached, and either warn and continue or treat this as answers get cached, and either warn and continue or treat this as
an error and refuse to load the configuration. an error and refuse to load the configuration.
This choice should be documented for the operator, for example in the This choice should be documented for the operator, for example in the
user manual. user manual.
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.
7.2.2. Intermediate Nameserver 7.2.2. Intermediate Nameserver
When an Intermediate Nameserver uses ECS, whether it passes an ECS When an Intermediate Nameserver uses ECS, whether it passes an ECS
option in its own response to its client is predicated on whether the option in its own response to its client is predicated on whether the
client originally included the option. Because a client that did not 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 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 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 option, the server MUST include one in its response, especially as it
could be talking to a Forwarding Resolver which would need the could be talking to a Forwarding Resolver which would need the
information for its own caching. information for its own caching.
skipping to change at page 12, line 42 skipping to change at page 13, line 22
When an Intermediate Nameserver receives a response containing an ECS When an Intermediate Nameserver receives a response containing an ECS
option and without the TC bit set, it SHOULD cache the result based 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 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 Resolver SHOULD retry the query over TCP to get the complete answer
section for caching. section for caching.
If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of 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 ADDRESS in the response don't match the non-zero fields in the
corresponding query, the full response MUST be dropped, as described corresponding query, the full response MUST be dropped, as described
in Section 11. For a response to a query which specified only the in Section 11. In a response to a query which specified only the
SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS
fields should contain the appropriate non-zero information for fields MUST contain the appropriate non-zero information that the
caching. Authoritative Nameserver used to generate the answer, so that it can
be cached accordingly.
If no ECS option is contained in the response, the Intermediate If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of addresses. See further discussion on the security implications of
this in Section 11. this in Section 11.
If a REFUSED response is received from an Authoritative Nameserver, If a REFUSED response is received from an Authoritative Nameserver,
an ECS-aware resolver MUST retry the query without ECS to distinguish an ECS-aware resolver MUST retry the query without ECS to distinguish
the response from one where the Authoritative Nameserver is not the response from one where the Authoritative Nameserver is not
responsible for the name, which is a common convention for the responsible for the name, which is a common convention for the
REFUSED status. Similarly, a client of a Recursive Resolver should REFUSED status. Similarly, a client of a Recursive Resolver SHOULD
retry for REFUSED because it is not sufficiently clear whether the retry for REFUSED because it is not sufficiently clear whether the
REFUSED was because of the ECS option or some other reason. REFUSED was because of the ECS option or some other reason.
7.3.1. Caching the Response 7.3.1. Caching the Response
In the cache, all resource records in the answer section MUST be tied In the cache, all resource records in the answer section MUST be to
to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- the network specified in the response. The appropriate prefix length
LENGTH fields, as limited by the Intermediate Nameserver's own depends on the relationship between SOURCE PREFIX-LENGTH, SCOPE
configuration for maximum cacheable prefix length. Note that the PREFIX-LENGTH, and the maximum cacheable prefix length configured for
additional and authority sections from a DNS response message are the cache.
specifically excluded here. Any records from these sections MUST NOT
be tied to a network. See more at Section 7.4. 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.
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.
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.
DNSKEY and DS records are the one exception to the above rules for
records in the answer section. These records SHOULD always be cached
at /0. See Section 9 for more.
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 Section 7.4.
Records that are cached as /0 because of a query's SOURCE PREFIX- 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 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 because of a response's SCOPE PREFIX-LENGTH of 0. The former should
only be used for other /0 queries that the Intermediate Resolver only be used for other /0 queries that the Intermediate Resolver
receives, but the latter is suitable as a response for all networks. receives, but the latter is suitable as a response for all networks.
Although omitting network-specific caching will significantly Although omitting network-specific caching will significantly
simplify an implementation, the resulting drop in cache hits is very simplify an implementation, the resulting drop in cache hits is very
likely to defeat most latency benefits provided by ECS. Therefore, likely to defeat most latency benefits provided by ECS. Therefore,
when implementing this option for latency purposes, implementing full implementing full caching support as described in this section is
caching support as described in this section is strongly recommended. strongly RECOMMENDED.
Enabling support for ECS in an Intermediate Nameserver will Enabling support for ECS in an Intermediate Nameserver will
significantly increase the size of the cache, reduce the number of significantly increase the size of the cache, reduce the number of
results that can be served from cache, and increase the load on the results that can be served from cache, and increase the load on the
server. Implementing the mitigation techniques described in server. Implementing the mitigation techniques described in
Section 11 is strongly recommended. Section 11 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.
7.3.2. Answering from Cache 7.3.2. Answering from Cache
Cache lookups are first done as usual for a DNS query, using the Cache lookups are first done as usual for a DNS query, using the
query tuple of <name, type, class>. Then the appropriate RRset MUST query tuple of <name, type, class>. Then the appropriate RRset MUST
be chosen based on longest prefix matching. The client address to be chosen based on longest prefix matching. The client address to
use for comparison will depend on whether the Intermediate Nameserver use for comparison will depend on whether the Intermediate Nameserver
received an ECS option in its client query. received an ECS option in its client query.
o If no ECS option was provided, the client's address is used. o If no ECS option was provided, the client's address is used.
o If there was an ECS option, the ADDRESS from it MAY be used if o If there was an ECS option specifying SOURCE PREFIX-LENGTH but no
local policy allows. Policy can vary depending on the agreements ADDRESS, the client's address is used but SOURCE PREFIX-LENGTH is
the operator of the Intermediate Nameserver has with Authoritative initially ignored. If no covering entry is found and SOURCE
Nameserver operators; see Section 12.2. If policy does not allow, PREFIX-LENGTH is shorter than the configured maximum length
a REFUSED response must be sent. 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.
o 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 Section 12.2. If
policy does not allow, a REFUSED response SHOULD be sent. See
Section 7.5 for more.
If a matching network is found and the relevant data is unexpired, If a matching network is found and the relevant data is unexpired,
the response is generated as per Section 7.2. the response is generated as per Section 7.2.
If no matching network is found, the Intermediate Nameserver MUST If no matching network is found, the Intermediate Nameserver MUST
perform resolution as usual. This is necessary to avoid Tailored perform resolution as usual. This is necessary to avoid Tailored
Responses in the cache from being returned to the wrong clients, and 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 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 from polluting the cache with a Tailored Response for all the users
of that resolver. of that resolver.
skipping to change at page 14, line 28 skipping to change at page 15, line 45
7.4. Delegations and Negative Answers 7.4. Delegations and Negative Answers
The prohibition against tying ECS data to records from the Authority The prohibition against tying ECS data to records from the Authority
and Additional section left an unfortunate ambiguity in the original and Additional section left an unfortunate ambiguity in the original
specification, primarily with regard to negative answers. The specification, primarily with regard to negative answers. The
expectation of the original authors was that ECS would only really be expectation of the original authors was that ECS would only really be
used for address requests and the positive result in the response's used for address requests and the positive result in the response's
answer section, the use case that was driving the definition of the answer section, the use case that was driving the definition of the
protocol. protocol.
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 authority 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.
For negative answers, some independent implementations of both For negative answers, some independent implementations of both
resolvers and authorities did not see the section restriction as resolvers and authorities did not see the section restriction as
necessarily meaning that a given name and type must only have either necessarily meaning that a given name and type must only have either
positive ECS-tagged answers or a negative answer. They support being 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, able to tell one part of the network that the data does not exist,
while telling another part of the network that it does. while telling another part of the network that it does.
Several other implementations, however, do not support being able to Several other implementations, however, do not support being able to
mix positive and negative answers, and thus interoperability is a mix positive and negative answers, and thus interoperability is a
problem. It is recommended that no specific behaviour regarding problem. It is recommended that no specific behavior regarding
negative answers be relied upon. negative answers be relied upon.
This issue is expected to be revisited in a future revision of the This issue is expected to be revisited in a future revision of the
protocol, possibly blessing the mixing of positive and negative protocol, possibly blessing the mixing of positive and negative
answers. There are implications for cache data structures that answers. There are implications for cache data structures that
developers should consider when writing new ECS code. developers should consider when writing new ECS code.
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.
7.5. Transitivity 7.5. Transitivity
Generally, ECS options will only be present in DNS messages between a Generally, ECS options will only be present in DNS messages between a
Recursive Resolver and an Authoritative Nameserver, i.e., one hop. Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
In certain configurations however, for example multi-tier nameserver In certain configurations however, for example multi-tier nameserver
setups, it may be necessary to implement transitive behaviour on setups, it may be necessary to implement transitive behavior on
Intermediate Nameservers. Intermediate Nameservers.
Any Intermediate Nameserver that forwards ECS options received from Any Intermediate Nameserver that forwards ECS options received from
their clients MUST fully implement the caching behaviour described in its clients MUST fully implement the caching behavior described in
Section 7.3. Section 7.3.
An Intermediate Nameserver MAY forward ECS options with address An Intermediate Nameserver MAY forward ECS options with address
information. This information MAY match the source IP address of the information. This information MAY match the source IP address of the
incoming query, and MAY have more or fewer address bits than the incoming query, and MAY have more or fewer address bits than the
Nameserver would normally include in a locally originated ECS option. Nameserver would normally include in a locally originated ECS option.
If an Intermediate Nameservers receives a query with SOURCE PREFIX- If an Intermediate Nameserver receives a query with SOURCE PREFIX-
LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace
it with more accurate address information. it with more accurate address information.
If for any reason the Intermediate Nameserver does not want to use If for any reason the Intermediate Nameserver does not want to use
the information in an ECS option it receives (too little address the information in an ECS option it receives (too little address
information, network address from a range not authorized to use the information, network address from a range not authorized to use the
server, private/unroutable address space, etc), it SHOULD drop the server, private/unroutable address space, etc), it SHOULD drop the
query and return a REFUSED response. Note again that a query MUST query and return a REFUSED response. Note again that a query MUST
NOT be refused solely because it provides 0 address bits. NOT be refused solely because it provides 0 address bits.
Be aware that at least one major existing implementation does not Be aware that at least one major existing implementation does not
return REFUSED and instead just process the query as though the return REFUSED and instead just processes the query as though the
problematic information were not present. This can lead to anomalous problematic information were not present. This can lead to anomalous
situations, such as a response from the Intermediate Nameserver that situations, such as a response from the Intermediate Nameserver that
indicates it is tailored for one network (the one passed in the indicates it is tailored for one network (the one passed in the
original query, since ADDRESS must match) when actually it is for original query, since ADDRESS must match) when actually it is for
another network (the one which contains the address that the another network (the one which contains the address that the
Intermediate Nameserver saw as making the query). Intermediate Nameserver saw as making the query).
8. IANA Considerations 8. IANA Considerations
IANA has already assigned option code 8 in the "DNS EDNS0 Option IANA has already assigned option code 8 in the "DNS EDNS0 Option
skipping to change at page 16, line 17 skipping to change at page 17, line 31
The presence or absence of an [RFC6891] EDNS0 OPT resource record The presence or absence of an [RFC6891] EDNS0 OPT resource record
containing an ECS option in a DNS query does not change the usage of containing an ECS option in a DNS query does not change the usage of
the resource records and mechanisms used to provide data origin the resource records and mechanisms used to provide data origin
authentication and data integrity to the DNS, as described in authentication and data integrity to the DNS, as described in
[RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed.
Use of this option, however, does imply increased DNS traffic between Use of this option, however, does imply increased DNS traffic between
any given Recursive Resolver and Authoritative Nameserver, which any given Recursive Resolver and Authoritative Nameserver, which
could be another barrier to further DNSSEC adoption in this area. could be another barrier to further DNSSEC adoption in this area.
It is expected that in a signed zone using ECS all signatures will
use the same DNSKEY record independent of the Tailored Response that
should be cached per network. Trying to establish a network-specific
chain of trust from a non-ECS-enabled zone into an ECS-enabled zone,
which tecnically feasbile, has no apparent benefits. Therefore,
while RRSIGs are obviously tied to the same network as the Tailored
Response that they cover, DNSKEY and DS records SHOULD be invariant
for all clients.
NSEC and NSEC3 are explicitly not addressed in this specification per
the discussion about negative answers in Section 7.4.
10. NAT Considerations 10. NAT Considerations
Special awareness of ECS in devices that perform Network Address Special awareness of ECS in devices that perform Network Address
Translation (NAT) as described in [RFC2663] is not required; queries Translation (NAT) as described in [RFC2663] is not required; queries
can be passed through as-is. The client's network address SHOULD NOT can be passed through as-is. The client's network address SHOULD NOT
be added, and existing ECS options, if present, SHOULD NOT be be added, and existing ECS options, if present, SHOULD NOT be
modified by NAT devices. modified by NAT devices.
In large-scale global networks behind a NAT device (but for example In large-scale global networks behind a NAT device (but for example
with Centralized Resolver infrastructure), an internal Intermediate with Centralized Resolver infrastructure), an internal Intermediate
Nameserver might have detailed network layout information, and may Nameserver might have detailed network layout information, and may
know which external subnets are used for egress traffic by each know which external subnets are used for egress traffic by each
internal network. In such cases, the Intermediate Nameserver MAY use internal network. In such cases, the Intermediate Nameserver MAY use
that information when originating ECS options. that information when originating ECS options.
In other cases, if a Recursive Resolvers knows it is sited behind a In other cases, if a Recursive Resolver knows it is sited behind a
NAT device, it SHOULD NOT originate ECS options with their external NAT device, it SHOULD NOT originate ECS options with their external
IP address, and instead rely on downstream Intermediate Nameservers IP address, and instead rely on downstream Intermediate Nameservers
to do so. They MAY, however, choose to include the option with their to do so. It MAY, however, choose to include the option with their
internal address for the purposes of signaling a shorter, more internal address for the purposes of signaling its own limit for
anonymous SOURCE PREFIX-LENGTH. SOURCE PREFIX-LENGTH.
If an Authoritative Nameserver on the publicly routed Internet Full treatment of special network addresses is beyond the scope of
receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] this document; handling them will likely differ according to the
private address space, it SHOULD ignore ADDRESS and look up its operational environments of each service provider. As a general
answer based on the address of the Recursive Resolver. In the guideline, if an Authoritative Nameserver on the publicly routed
Internet receives a query that specifies an ADDRESS in [RFC1918] or
[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 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 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- with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX-
LENGTH of 8. The Intermediate Nameserver MAY elect to cache the LENGTH of 8. The Intermediate Nameserver MAY elect to cache the
answer under one entry for special-purpose addresses [RFC6890]; see answer under one entry for special-purpose addresses [RFC6890]; see
Section 11.3. Section 11.3.
11. Security Considerations 11. Security Considerations
11.1. Privacy 11.1. Privacy
skipping to change at page 17, line 25 skipping to change at page 19, line 5
encouraged to conceal part of the IP address of the user by encouraged to conceal part of the IP address of the user by
truncating IPv4 addresses to 24 bits. 56 bits are recommended for truncating IPv4 addresses to 24 bits. 56 bits are recommended for
IPv6, based on [RFC6177]. IPv6, based on [RFC6177].
ISPs should have more detailed knowledge of their own networks. That 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 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 area. In those cases, for optimal cache utilization and improved
privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in
this /20 to just 20 bits, instead of 24 as recommended above. this /20 to just 20 bits, instead of 24 as recommended above.
Users who wish their full IP address to be hidden can include an ECS Users who wish their full IP address to be hidden need to configure
option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of their client software, if possible, to include an ECS option
0). As described in previous sections, this option will be forwarded 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 across all the Recursive Resolvers supporting ECS, which MUST NOT
modify it to include the network address of the client. modify it to include the network address of the client.
Note that even without an ECS option, any server queried directly by 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 the user will be able to see the full client IP address. Recursive
Resolvers or Authoritative Nameservers MAY use the source IP address Resolvers or Authoritative Nameservers MAY use the source IP address
of queries to return a cached entry or to generate a Tailored of queries to return a cached entry or to generate a Tailored
Response that best matches the query. Response that best matches the query.
11.2. Birthday Attacks 11.2. Birthday Attacks
skipping to change at page 18, line 51 skipping to change at page 20, line 33
Even without malicious intent, Centralized Resolvers providing Even without malicious intent, Centralized Resolvers providing
answers to clients in multiple networks will need to cache different answers to clients in multiple networks will need to cache different
responses for different networks, putting more memory pressure on the responses for different networks, putting more memory pressure on the
cache. cache.
To mitigate those problems: To mitigate those problems:
o Recursive Resolvers implementing ECS should only enable it in o Recursive Resolvers implementing ECS should only enable it in
deployments where it is expected to bring clear advantages to the deployments where it is expected to bring clear advantages to the
end users. For example, when expecting clients from a variety of end users, such as when expecting clients from a variety of
networks or from a wide geographical area. Due to the high cache networks or from a wide geographical area. Due to the high cache
pressure introduced by ECS, the feature SHOULD be disabled in all pressure introduced by ECS, the feature SHOULD be disabled in all
default configurations. default configurations.
o Recursive Resolvers SHOULD limit the number of networks and o Recursive Resolvers SHOULD limit the number of networks and
answers they keep in the cache for any given query. answers they keep in the cache for any given query.
o Recursive Resolvers SHOULD limit the number of total different o Recursive Resolvers SHOULD limit the number of total different
networks that they keep in cache. networks that they keep in cache.
skipping to change at page 19, line 31 skipping to change at page 21, line 13
specific cache entries first. specific cache entries first.
o Authoritative Nameservers and Recursive Resolvers should discard o Authoritative Nameservers and Recursive Resolvers should discard
ECS options that are either obviously forged or otherwise known to ECS options that are either obviously forged or otherwise known to
be wrong. They SHOULD at least treat unroutable addresses, such be wrong. They SHOULD at least treat unroutable addresses, such
as some of the address blocks defined in [RFC6890], as equivalent as some of the address blocks defined in [RFC6890], as equivalent
to the Recursive Resolver's own identity. They SHOULD ignore and to the Recursive Resolver's own identity. They SHOULD ignore and
never forward ECS options specifying other routable addresses that never forward ECS options specifying other routable addresses that
are known not to be served by the query source. are known not to be served by the query source.
o Authoritative Nameservers consider the ECS option just as a hint o The ECS option is just a hint to Authoritative Nameservers for
to provide better results. They can decide to ignore the content customizing results. They can decide to ignore the content of the
of the ECS option based on black or white lists, rate limiting ECS option based on black or white lists, rate limiting
mechanisms, or any other logic implemented in the software. mechanisms, or any other logic implemented in the software.
12. Sending the Option 12. Sending the Option
When implementing a Recursive Resolver, there are two strategies on When implementing a Recursive Resolver, there are two strategies on
deciding when to include an ECS option in a query. At this stage, deciding when to include an ECS option in a query. At this stage,
it's not clear which strategy is best. it's not clear which strategy is best.
12.1. Probing 12.1. Probing
skipping to change at page 20, line 41 skipping to change at page 22, line 23
an implementation could use a whitelist of Authoritative Nameservers an implementation could use a whitelist of Authoritative Nameservers
to send the option to, likely specified by their domain name. to send the option to, likely specified by their domain name.
Implementations MAY also allow additionally configuring this based on Implementations MAY also allow additionally configuring this based on
other criteria, such as zone or query type. As of the time of this other criteria, such as zone or query type. As of the time of this
writing, at least one implementation makes use of a whitelist. writing, at least one implementation makes use of a whitelist.
An advantage of using a whitelist is that partial client address An advantage of using a whitelist is that partial client address
information is only disclosed to Nameservers that are known to use information is only disclosed to Nameservers that are known to use
the information, improving privacy. the information, improving privacy.
A drawback is saleability. The operator needs to track which A drawback is scalability. The operator needs to track which
Authoritative Nameservers support ECS, making it harder for new Authoritative Nameservers support ECS, making it harder for new
Authoritative Nameservers to start using the option. Authoritative Nameservers to start using the option.
Similarly, Authoritative Nameservers can also use whitelists to limit Similarly, Authoritative Nameservers can also use whitelists to limit
the feature to only certain clients. For example, a CDN that does the feature to only certain clients. For example, a CDN that does
not want all of their mapping trivially walked might require a legal not want all of their mapping trivially walked might require a legal
agreement with the Recursive Resolver operator, to clearly describe agreement with the Recursive Resolver operator, to clearly describe
the acceptable use of the feature. the acceptable use of the feature.
The maintenance of access control mechanisms is out of scope for this The maintenance of access control mechanisms is out of scope for this
protocol definition. protocol definition.
13. Example 13. Example
1. A stub resolver, SR, with IP address 192.0.2.37 tries to resolve 1. A stub resolver, SR, with IP address 192.0.2.37, tries to
www.example.com, by forwarding the query to the Recursive resolve www.example.com by forwarding the query to the Recursive
Resolver, RNS, from IP address IP, asking for recursion. Resolver, RNS, asking for recursion.
2. RNS, supporting ECS, looks up www.example.com in its cache. An 2. RNS, supporting ECS, looks up www.example.com in its cache. An
entry is found neither for www.example.com, nor for example.com. entry is found neither for www.example.com, nor for example.com.
3. RNS builds a query to send to the root and .com servers. The 3. RNS builds a query to send to the root and .com servers. The
implementation of RNS provides facilities so an administrator implementation of RNS provides facilities so an administrator
can configure it not to forward ECS in certain cases. In can configure it not to forward ECS in certain cases. In
particular, RNS is configured to not include an ECS option when particular, RNS is configured to not include an ECS option when
talking to TLD or root nameservers, as described in Section 7.1. talking to TLD or root nameservers, as described in Section 7.1.
Thus, no ECS option is added, and resolution is performed as Thus, no ECS option is added, and resolution is performed as
skipping to change at page 23, line 29 skipping to change at page 25, line 9
drafts of this document and for providing useful feedback: Paul S. drafts of this document and for providing useful feedback: Paul S.
R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto, R. Chisholm, B. Narendran, Leonidas Kontothanassis, David Presotto,
Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren
Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro,
Edward Lewis, and Eric Burger from Neustar; David Ulevitch and Edward Lewis, and Eric Burger from Neustar; David Ulevitch and
Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from
Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya
Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from
Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs; Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs;
Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn
Gillmor from the ACLU, Russ Housley and all of the other people that Gillmor from the ACLU; Evan Hunt and Mukund Sivaraman from the
replied to our emails on various mailing lists. 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.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 25, line 11 skipping to change at page 26, line 42
"Address Family Numbers", "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/ <http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>. address-family-numbers.xhtml>.
[DPRIVE_Working_Group] [DPRIVE_Working_Group]
"DPRIVE Working Group", "DPRIVE Working Group",
<https://datatracker.ietf.org/wg/dprive/charter/>. <https://datatracker.ietf.org/wg/dprive/charter/>.
[I-D.hardie-privsec-metadata-insertion] [I-D.hardie-privsec-metadata-insertion]
Hardie, T., "Design considerations for Metadata Hardie, T., "Design considerations for Metadata
Insertion", draft-hardie-privsec-metadata-insertion-00 Insertion", draft-hardie-privsec-metadata-insertion-02
(work in progress), October 2015. (work in progress), March 2016.
[I-D.vandergaast-edns-client-subnet] [I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis, Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
"Client Subnet in DNS Requests", draft-vandergaast-edns- "Client Subnet in DNS Requests", draft-vandergaast-edns-
client-subnet-02 (work in progress), July 2013. client-subnet-02 (work in progress), July 2013.
[Public_Suffix_List] [Public_Suffix_List]
"Public Suffix List", <https://publicsuffix.org/>. "Public Suffix List", <https://publicsuffix.org/>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>. <http://www.rfc-editor.org/info/rfc2308>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, DOI 10.17487/RFC2663, August 1999, 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>. <http://www.rfc-editor.org/info/rfc2663>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
Appendix A. Document History Appendix A. Document History
[RFC Editor: Please delete this section before publication.] [RFC Editor: Please delete this section before publication.]
-06 to -07:
o Minor comments from Suzanne, Mukund, Jinmei and from the IESG on
the dnsop list.
o 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.
-05 to -06: -05 to -06:
o Integrated David Lawrence comments. o Integrated David Lawrence comments.
o Ran spellcheck again. One ady I';; laern to tyoe/ o Ran spellcheck again. One ady I';; laern to tyoe/
-04 to -05: -04 to -05:
o Moved comment about retrying for REFUSED to section on "Handling o Moved comment about retrying for REFUSED to section on "Handling
ECS Responses". (Jinmei) ECS Responses". (Jinmei)
 End of changes. 54 change blocks. 
156 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/