< draft-ietf-dnsop-edns-client-subnet-03.txt   draft-ietf-dnsop-edns-client-subnet-04.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: February 25, 2016 D. Lawrence Expires: March 28, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
August 24, 2015 September 25, 2015
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-03 draft-ietf-dnsop-edns-client-subnet-04
Abstract Abstract
This draft defines an EDNS0 extension to carry information about the This draft defines an EDNS0 extension to carry information about the
network that originated a DNS query, and the network for which the network that originated a DNS query, and the network for which the
subsequent response can be cached. subsequent response can be cached.
IESG Note
[RFC Editor: Please remove this note prior to publication ]
This informational document describes an existing, implemented and
deployed system. A subset of the operators using this is at
http://www.afasterinternet.com/participants.htm . The authors believe
that it is better to document this system (even if not everyone
agrees with the concept) than leave it undocumented and proprietary.
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 February 25, 2016. This Internet-Draft will expire on March 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
6.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 7 7.1. Originating the Option . . . . . . . . . . . . . . . . . 7
6.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 8 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8
6.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9
6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 7.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
6.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 11 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9
6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 11
6.3.1. Caching the Response . . . . . . . . . . . . . . . . 12 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12
6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 12
6.4. Delegations and Negative Answers . . . . . . . . . . . . 13 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13
6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Delegations and Negative Answers . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14
8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16
10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 17
11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 18
11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 19
11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 20
13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 24 16.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 16.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Document History . . . . . . . . . . . . . . . . . . 24 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Document History . . . . . . . . . . . . . . . . . . 25
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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.
skipping to change at page 4, line 13 skipping to change at page 3, line 51
would benefit from the extension and not for general purpose would benefit from the extension and not for general purpose
deployment. It is completely optional and can safely be ignored by deployment. It is completely optional and can safely be ignored by
servers that choose not to implement it or enable it. servers that choose not to implement it or enable it.
This draft also includes guidelines on how to best cache those This draft 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 had been At least a dozen different client and server implementations had been
written based on the original specification, first known as draft- written based on the original specification, first known as draft-
vandergaast-edns-client-subnet. While they interoperate for the vandergaast-edns-client-subnet [1]. The protocol is in active
primary goal, they have varying behaviour around poorly specified production use among several major Internet companies, a subset of
edge cases. Known incompatibilities will be described. which are listed at http://www.afasterinternet.com/participants.htm .
While they interoperate for the primary goal, they have varying
behaviour around poorly specified edge cases. Known
incompatibilities will be described. The authors believe that it is
better to document this system, even if not everyone agrees with the
concept or the details of the original specification, rather than
leave it undocumented and proprietary.
2. Requirements Notation 2. Privacy Note
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.
The IETF is actively working on enhancing DNS privacy [3], and the
re-injection of metadata has been identified as a problematic design
pattern [4].
As noted above, however, this document primarily describes existing
behavior of a deployed method, to further the understanding of the
Internet community.
We encourage the deployment of means to allow users to make use of
the opt-out provided. We also recommend that others avoid techniques
that may introduce additional metadata in future work, as it may
damage user trust.
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].
3. Terminology 4. Terminology
ECS EDNS Client Subnet. ECS EDNS Client Subnet.
Client A Stub Resolver, Forwarder or Recursive Resolver. A client Client A Stub Resolver, Forwarder or Recursive Resolver. A client
to a Recursive Resolver or a Forwarder. to a Recursive Resolver or a Forwarder.
Server A Forwarder, Recursive Resolver or Authoritative Nameserver. Server A Forwarder, Recursive Resolver or Authoritative Nameserver.
Stub Resolver: A simple DNS protocol implementation on the client Stub Resolver: A simple DNS protocol implementation on the client
side as described in [RFC1034] section 5.3.1. A client to a side as described in [RFC1034] section 5.3.1. A client to a
skipping to change at page 5, line 20 skipping to change at page 5, line 32
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.
4. 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 5, and is meant to The format of this option is described in Section 6, and is meant to
be added in queries sent by Intermediate Nameservers in a way be added in queries sent by Intermediate Nameservers in a way
transparent to Stub Resolvers and end users, as described in transparent to Stub Resolvers and end users, as described in
Section 6.1. ECS is only defined for the Internet (IN) DNS class. Section 7.1. ECS is only defined for the Internet (IN) DNS class.
As described in Section 6.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 this EDNS0 option as a hint to better locate the network of the end
user and provide a better answer. user and provide a better answer.
Its response would contain an edns-client-subnet (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 6.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 6.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 10 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 location, which is a
common occurrence in current content delivery network (CDN) setups. common occurrence in current content delivery network (CDN) setups.
Section 6.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.
5. Option Format 6. Option Format
This protocol uses an EDNS0 [RFC6891]) option to include client This protocol uses an EDNS0 [RFC6891]) option to include client
address information in DNS messages. The option is structured as address information in DNS messages. The option is structured as
follows: follows:
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE | 0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH | 2: | OPTION-LENGTH |
skipping to change at page 6, line 47 skipping to change at page 7, line 13
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00
0x08). 0x08).
o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the
length of the payload (everything after OPTION-LENGTH) in octets. length of the payload (everything after OPTION-LENGTH) in octets.
o FAMILY, 2 octets, indicates the family of the address contained in o FAMILY, 2 octets, indicates the family of the address contained in
the option, using address family codes as assigned by IANA in the option, using address family codes as assigned by IANA in
IANA-AFI [2]. IANA-AFI [5].
The format of the address part depends on the value of FAMILY. This 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 document only defines the format for FAMILY 1 (IP version 4) and 2
(IP version 6), which are as follows: (IP version 6), which are as follows:
o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
significant bits of ADDRESS to be used for the lookup. In significant bits of ADDRESS to be used for the lookup. In
responses, it mirrors the same value as in the queries. responses, it mirrors the same value as in the queries.
o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost
significant bits of ADDRESS that the response covers. In queries, significant bits of ADDRESS that the response covers. In queries,
it MUST be set to 0. 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, truncated to the number of bits IPv6 address, depending on FAMILY, which MUST be truncated to the
indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to number of bits indicated by the SOURCE PREFIX-LENGTH field,
pad to the end of the last octet needed. Trailing all-zero octets padding with 0 bits to pad to the end of the last octet needed.
SHOULD be omitted.
o A server receiving an ECS option that uses more ADDRESS octets
than are needed, or that has non-zero bits set beyond SOURCE
PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a
signal to the developer of the software making the request to 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).
6. Protocol Description 7. Protocol Description
6.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 11. The querying Authoritative Nameservers, as described in Section 12. The
option can also be initialized by a Stub Resolver or Forwarder. option can also be initialized by a Stub Resolver or Forwarder.
6.1.1. Recursive Resolvers 7.1.1. Recursive Resolvers
The setup of the ECS option in a Recursive Resolver depends on the The setup of the ECS option in a Recursive Resolver depends on the
client query that triggered the resolution process. client query that triggered the resolution process.
In the usual case, where no ECS option was present in the client In the usual case, where no ECS option was present in the client
query, the Recursive Resolver initializes the option by setting the query, the Recursive Resolver initializes the option by setting the
FAMILY of the client's address. It then uses the value of its FAMILY of the client's address. It then uses the value of its
maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For
privacy reasons, and because the whole IP address is rarely required privacy reasons, and because the whole IP address is rarely required
to determine a tailored response, this length SHOULD be shorter than to determine a tailored response, this length SHOULD be shorter than
the full address, as described in Section 10. the full address, as described in Section 11.
If the triggering query included an ECS option itself, it MUST be If the triggering query included an ECS option itself, it MUST be
examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's
outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of
the incoming query's SOURCE PREFIX-LENGTH or the server's maximum the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
cacheable prefix length. cacheable prefix length.
Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the 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, 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 with trailing 0 bits added, if needed, to fill the final octet. The
total number of octets used should only be enough to cover SOURCE total number of octets used MUST only be enough to cover SOURCE
PREFIX-LENGTH bits, rather than the full width that would normally be PREFIX-LENGTH bits, rather than the full width that would normally be
used by addresses in FAMILY. used by addresses in FAMILY.
FAMILY and ADDRESS information MAY be used from the ECS option in the FAMILY and ADDRESS information MAY be used from the ECS option in the
incoming query. Passing the existing address data is supportive of incoming query. Passing the existing address data is supportive of
the Recursive Resolver being used as the target of a Forwarder, but the Recursive Resolver being used as the target of a Forwarder, but
could possibly run into policy problems with regard to usage could possibly run into policy problems with regard to usage
agreements between the Recursive Resolver and Authoritative agreements between the Recursive Resolver and Authoritative
Namserver. See Section 11.2 for more discussion on this point. If Namserver. See Section 12.2 for more discussion on this point. If
the Recursive Resolver will not forward the FAMILY and ADDRESS data the Recursive Resolver will not forward the FAMILY and ADDRESS data
from the incoming ECS option, it SHOULD return a REFUSED response. from the incoming ECS option, it SHOULD return a REFUSED response.
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 a lame delegation, which is the common convention the response from a lame delegation, which is the common convention
for a REFUSED status. for a REFUSED status.
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.
6.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 set to
indicate its own level of privacy via SOURCE PREFIX-LENGTH. An indicate its own level of privacy via SOURCE PREFIX-LENGTH. An
Intermediate Nameserver that receives such a query MUST NOT make Intermediate Nameserver that receives such a query MUST NOT make
queries that include more bits of client address than in the 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
skipping to change at page 9, line 5 skipping to change at page 9, line 30
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,
FAMILY MUST be set to 0. FAMILY MUST be set to 0.
6.1.3. Forwarders 7.1.3. Forwarders
Forwarders essentially appear to be Stub Resolvers to whatever Forwarders essentially appear to be Stub Resolvers to whatever
Recursive Resolver is ultimately handling the query, but look like a Recursive Resolver is ultimately handling the query, but look like a
Recursive Resolver to their client. A Forwarder using this option Recursive Resolver to their client. A Forwarder using this option
MUST prepare it as described in the Section 6.1.1 section above. In MUST prepare it as described in the Section 7.1.1 section above. In
particular, a Forwarder that implements this protocol MUST honor particular, a Forwarder that implements this protocol MUST honor
SOURCE PREFIX-LENGTH restrictions indicated in the incoming query SOURCE PREFIX-LENGTH restrictions indicated in the incoming query
from its client. See also Section 6.5. from its client. See also Section 7.5.
Since the Recursive Resolver it contacts will essentially treat it as Since the Recursive Resolver it contacts will essentially treat it as
a Stub Resolver, the Forwarder must be prepared for a REFUSED a Stub Resolver, the Forwarder must be prepared for a REFUSED
response if the Recursive Resolver does not permit incoming ADDRESS response if the Recursive Resolver does not permit incoming ADDRESS
information. The Forwarded MUST retry with FAMILY and ADDRESS set to information. The Forwarded MUST retry with FAMILY and ADDRESS set to
0. 0.
6.2. Generating a Response 7.2. Generating a Response
6.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
support for the ECS option ought to safely ignore it within incoming support for the ECS option ought to safely ignore it within incoming
queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include
an ECS option within replies, to indicate lack of support for it. an ECS option within replies, to indicate lack of support for it.
Implementers of Intermediate Nameservers should be aware, however, Implementers of Intermediate Nameservers should be aware, however,
skipping to change at page 10, line 9 skipping to change at page 10, line 34
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 (with FAMILY and ADDRESS set to 0).
Echoing back these values helps to mitigate certain attack vectors, Echoing back these values helps to mitigate certain attack vectors,
as described in Section 10. 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.
skipping to change at page 11, line 19 skipping to change at page 11, line 43
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.
Implementations SHOULD document their chosen behavior. Implementations SHOULD document their chosen behavior.
6.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 Forwarder which would need the information for could be talking to a Forwarder which would need the information for
its own caching. its own caching.
skipping to change at page 11, line 45 skipping to change at page 12, line 20
with a longer SOURCE PREFIX-LENGTH to get a better reply before 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 responding to its client, as long as it does not exceed a SOURCE
PREFIX-LENGTH specified in the query that triggered resolution, but PREFIX-LENGTH specified in the query that triggered resolution, but
this obviously has implications for the latency of the overall this obviously has implications for the latency of the overall
lookup. lookup.
The logic for using the cache to determine whether the Intermediate The logic for using the cache to determine whether the Intermediate
Nameserver already knows the response to provide to its client is Nameserver already knows the response to provide to its client is
covered in the next section. covered in the next section.
6.3. Handling ECS Responses and Caching 7.3. Handling ECS Responses and Caching
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 10. For a response to a query which specified only the in Section 11. For 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 should contain the appropriate non-zero information for
caching. caching.
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 10. this in Section 11.
6.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 tied
to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX-
LENGTH fields, as limited by the Intermediate Nameserver's own LENGTH fields, as limited by the Intermediate Nameserver's own
configuration for maximum cacheable prefix length. Note that the configuration for maximum cacheable prefix length. Note that the
additional and authority sections from a DNS response message are additional and authority sections from a DNS response message are
specifically excluded here. Any records from these sections MUST NOT specifically excluded here. Any records from these sections MUST NOT
be tied to a network. See more at Section 6.4. 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 when implementing this option for latency purposes, implementing full
caching support as described in this section is strongly recommended. caching support as described in this section is 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 10 is strongly recommended. Section 11 is strongly recommended.
6.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, the ADDRESS from it MAY be used if
local policy allows. Policy can vary depending on the agreements local policy allows. Policy can vary depending on the agreements
the operator of the Intermediate Nameserver has with Authoritative the operator of the Intermediate Nameserver has with Authoritative
Nameserver operators; see Section 11.2. If policy does not allow, Nameserver operators; see Section 12.2. If policy does not allow,
a REFUSED response must be sent. a REFUSED response must be sent.
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 6.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.
6.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 records, the use case that was driving the used for address records, the use case that was driving the
definition of the protocol. definition of the protocol.
The delegations case is a bit easier to tease out. In operational The delegations case is a bit easier to tease out. In operational
practice, if an authoritative server is using address information to practice, if an authoritative server is using address information to
skipping to change at page 14, line 14 skipping to change at page 14, line 39
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. problem.
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.
6.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 behaviour on
Intermediate Nameservers. Intermediate Nameservers.
It is important that any Intermediate Nameserver that forwards ECS It is important that any Intermediate Nameserver that forwards ECS
options received from their clients MUST fully implement the caching options received from their clients MUST fully implement the caching
behaviour described in Section 6.3. behaviour described in Section 7.3.
Intermediate Nameservers supporting ECS MUST forward options with Intermediate Nameservers supporting ECS MUST forward options with
SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such
options MUST NOT be replaced with more accurate address information. options MUST NOT be replaced with more accurate address information.
An Intermediate Nameserver MAY also forward ECS options with actual An Intermediate Nameserver MAY also forward ECS options with actual
address information. This information MAY match the source IP address information. This information MAY match the source IP
address of the incoming query, and MAY have more or fewer address address of the incoming query, and MAY have more or fewer address
bits than the Nameserver would normally include in a locally bits than the Nameserver would normally include in a locally
originated ECS option. originated ECS option.
skipping to change at page 15, line 5 skipping to change at page 15, line 31
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 process 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).
7. 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
Codes (OPT)" registry to ECS. Codes (OPT)" registry to ECS.
The IANA is requested to update the reference ("draft-vandergaast- The IANA is requested to update the reference ("draft-vandergaast-
edns-client-subnet") to refer to this RFC when published. edns-client-subnet") to refer to this RFC when published.
8. DNSSEC Considerations 9. DNSSEC Considerations
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.
9. 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
skipping to change at page 16, line 7 skipping to change at page 16, line 36
If an Authoritative Nameserver on the publicly routed Internet If an Authoritative Nameserver on the publicly routed Internet
receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193]
private address space, it SHOULD ignore ADDRESS and look up its private address space, it SHOULD ignore ADDRESS and look up its
answer based on the address of the Recursive Resolver. In the 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 10.3. Section 11.3.
10. Security Considerations 11. Security Considerations
10.1. Privacy 11.1. Privacy
With the ECS option, the network address of the client that initiated With the ECS option, the network address of the client that initiated
the resolution becomes visible to all servers involved in the the resolution becomes visible to all servers involved in the
resolution process. Additionally, it will be visible from any resolution process. Additionally, it will be visible from any
network traversed by the DNS packets. network traversed by the DNS packets.
To protect users' privacy, Recursive Resolvers are strongly To protect users' privacy, Recursive Resolvers are strongly
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].
skipping to change at page 16, line 41 skipping to change at page 17, line 23
0). As described in previous sections, this option will be forwarded 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.
10.2. Birthday Attacks 11.2. Birthday Attacks
ECS adds information to the DNS query tupe (q-tuple). This allows an ECS adds information to the DNS query tupe (q-tuple). This allows an
attacker to send a caching Intermediate Nameserver multiple queries attacker to send a caching Intermediate Nameserver multiple queries
with spoofed IP addresses either in the ECS option or as the source with spoofed IP addresses either in the ECS option or as the source
IP. These queries will trigger multiple outgoing queries with the IP. These queries will trigger multiple outgoing queries with the
same name, type and class, just different address information in the same name, type and class, just different address information in the
ECS option. ECS option.
With multiple queries for the same name in flight, the attacker has a 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 higher chance of success to send a matching response with the SCOPE
PREFIX-LENGTH set to 0 to get it cached for all hosts. PREFIX-LENGTH set to 0 to get it cached for all hosts.
To counter this, the ECS option in a response packet MUST contain the To counter this, the ECS option in a response packet MUST contain the
full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the
corresponding query. Intermediate Nameservers processing a response corresponding query. Intermediate Nameservers processing a response
MUST verify that these match, and SHOULD discard the entire response MUST verify that these match, and SHOULD discard the entire response
if they do not. if they do not.
That requirement to discard is "SHOULD" instead of "MUST" because it That requirement to discard is "SHOULD" instead of "MUST" because it
stands in opposition to the instruction in Section 6.3 which states stands in opposition to the instruction in Section 7.3 which states
that a response lacking an ECS option should be treated as though it 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 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 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 data and just needs to flood back responses that have no ECS
option at all. option at all.
This type of attack could be detected in ongoing operations by This type of attack could be detected in ongoing operations by
marking whether the responding nameserver had previously been sending marking whether the responding nameserver had previously been sending
ECS option, and/or by taking note of an incoming flood of bogus ECS option, and/or by taking note of an incoming flood of bogus
responses and flagging the relevant query for re-resolution. This is responses and flagging the relevant query for re-resolution. This is
more complex than existing nameserver responses to spoof floods, and more complex than existing nameserver responses to spoof floods, and
would also need to be sensitive to a nameserver legitimately stopping would also need to be sensitive to a nameserver legitimately stopping
ECS replies even though it had previously given them. ECS replies even though it had previously given them.
10.3. Cache Pollution 11.3. Cache Pollution
It is simple for an arbitrary resolver or client to provide false It is simple for an arbitrary resolver or client to provide false
information in the ECS option, or to send UDP packets with forged information in the ECS option, or to send UDP packets with forged
source IP addresses. source IP addresses.
This could be used to: This could be used to:
o pollute the cache of intermediate resolvers, by filling it with o pollute the cache of intermediate resolvers, by filling it with
results that will rarely (if ever) be used. results that will rarely (if ever) be used.
skipping to change at page 18, line 44 skipping to change at page 19, line 23
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 Authoritative Nameservers consider the ECS option just as a hint
to provide better results. They can decide to ignore the content to provide better results. They can decide to ignore the content
of the ECS option based on black or white lists, rate limiting of the 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.
11. 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.
11.1. Probing 12.1. Probing
A Recursive Resolver can send the ECS option with every outgoing A Recursive Resolver can send the ECS option with every outgoing
query. However, it is RECOMMENDED that Resolvers remember which query. However, it is RECOMMENDED that Resolvers remember which
Authoritative Nameservers did not return the option with their Authoritative Nameservers did not return the option with their
response, and omit client address information from subsequent queries response, and omit client address information from subsequent queries
to those Nameservers. to those Nameservers.
Additionally, Recursive Resolvers SHOULD be configured to never send Additionally, Recursive Resolvers SHOULD be configured to never send
the option when querying root, top-level, and effective top-level the option when querying root, top-level, and effective top-level
domain servers. These domains are delegation-centric and are very domain servers. These domains are delegation-centric and are very
skipping to change at page 19, line 34 skipping to change at page 20, line 9
Probing, if implemented, MUST be repeated periodically, e.g., daily. Probing, if implemented, MUST be repeated periodically, e.g., daily.
If an Authoritative Nameserver indicates ECS support for one zone, it If an Authoritative Nameserver indicates ECS support for one zone, it
is to be expected that the Nameserver supports ECS for all of its is to be expected that the Nameserver supports ECS for all of its
zones. Likewise, an Authoritative Nameserver that uses ECS zones. Likewise, an Authoritative Nameserver that uses ECS
information for one of its zones, MUST indicate support for the information for one of its zones, MUST indicate support for the
option in all of its responses to ECS queries. If the option is option in all of its responses to ECS queries. If the option is
supported but not actually used for generating a response, its SCOPE supported but not actually used for generating a response, its SCOPE
PREFIX-LENGTH MUST be set to 0. PREFIX-LENGTH MUST be set to 0.
11.2. Whitelist 12.2. Whitelist
As described previously, it is expected that only a few Recursive As described previously, it is expected that only a few Recursive
Resolvers will need to use ECS, and that it will generally be enabled Resolvers will need to use ECS, and that it will generally be enabled
only if it offers a clear benefit to the users. only if it offers a clear benefit to the users.
To avoid the complexity of implementing a probing and detection To avoid the complexity of implementing a probing and detection
mechanism (and the possible query loss/delay that may come with it), mechanism (and the possible query loss/delay that may come with it),
an implementation could use a whitelist of Authoritative Namesevers an implementation could use a whitelist of Authoritative Namesevers
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
skipping to change at page 20, line 18 skipping to change at page 20, line 40
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.
12. 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 resolve
www.example.com, by forwarding the query to the Recursive www.example.com, by forwarding the query to the Recursive
Resolver, RNS, from IP address IP, asking for recursion. Resolver, RNS, from IP address IP, 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 6.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
usual. usual.
4. RNS now knows the next server to query: the Authoritative 4. RNS now knows the next server to query: the Authoritative
Nameserver, ANS, responsible for example.com. Nameserver, ANS, responsible for example.com.
5. RNS prepares a new query for www.example.com, including an ECS 5. RNS prepares a new query for www.example.com, including an ECS
option with: option with:
* OPTION-CODE, set to 8. * OPTION-CODE, set to 8.
skipping to change at page 21, line 48 skipping to change at page 22, line 24
ECS option. ECS option.
12. RNS receives another query to resolve www.example.com. This 12. RNS receives another query to resolve www.example.com. This
time, a response is cached. The response, however, is tied to a time, a response is cached. The response, however, is tied to a
particular network. If the address of the client matches any particular network. If the address of the client matches any
network in the cache, then the response is returned from the network in the cache, then the response is returned from the
cache. Otherwise, another query is performed. If multiple cache. Otherwise, another query is performed. If multiple
results match, the one with the longest SCOPE PREFIX-LENGTH is results match, the one with the longest SCOPE PREFIX-LENGTH is
chosen, as per common best-network match algorithms. chosen, as per common best-network match algorithms.
13. Contributing Authors 14. Contributing Authors
The below individuals contributed significantly to the draft. The The below individuals contributed significantly to the draft. The
RFC Editor prefers a maximum of 5 names on the front page, and so we RFC Editor prefers a maximum of 5 names on the front page, and so we
have listed additional authors in this section have listed additional authors in this section
Edward Lewis Edward Lewis
ICANN ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles CA 90094-2536 Los Angeles CA 90094-2536
USA USA
Email: edward.lewis@icann.org Email: edward.lewis@icann.org
Sean Leach Sean Leach
Fastly Fastly
POBox 78266 POBox 78266
San Francisco CA 94107 San Francisco CA 94107
Jason Moreau Jason Moreau
Akamai Technologies Akamai Technologies
8 Cambridge Ctr 8 Cambridge Ctr
Cambridge MA 02142-1413 Cambridge MA 02142-1413
USA USA
14. Acknowledgements 15. Acknowledgements
The authors wish to thank Darryl Rodden for his work as a co-author The authors wish to thank Darryl Rodden for his work as a co-author
on previous versions, and the following people for reviewing early on previous versions, and the following people for reviewing early
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 Internet Software Consortium; Andrew Sullivan from Dyn; Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn;
John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer
from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin; from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin;
and all of the other people that replied to our emails on various and all of the other people that replied to our emails on various
mailing lists. mailing lists.
15. References 16. References
15.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
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
skipping to change at page 24, line 5 skipping to change at page 24, line 29
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, DOI 10.17487/RFC6890, April 2013, 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>. <http://www.rfc-editor.org/info/rfc6890>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013, RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
15.2. Informative References 16.2. Informative References
[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>.
15.3. URIs 16.3. URIs
[1] http://www.iana.org/assignments/address-family-numbers/ [1] https://tools.ietf.org/html/draft-vandergaast-edns-client-
subnet-00
[3] https://datatracker.ietf.org/doc/charter-ietf-dprive/
[4] https://github.com/IAB-PrivSec-program/draft-iab-privsec-
metadata-insertion/blob/master/draft-iab-privsec-metadata-
insertion.md
[5] http://www.iana.org/assignments/address-family-numbers/
Appendix A. Document History Appendix A. Document History
[RFC Editor: Please delete this section before publication.] [RFC Editor: Please delete this section before publication.]
-03 to -04:
o Privacy note per Ted Hardie's suggestion.
o MUST use minimum octet length to cover PREFIX bits.
o Expose note about documenting deployed, if flawed, protocol.
-02 to -03: -02 to -03:
o Some cleanup of the whitelist text. o Some cleanup of the whitelist text.
-01 to -02 (IETF) -01 to -02 (IETF)
o Clean up the open issues, mostly by saying that they were out of o Clean up the open issues, mostly by saying that they were out of
scope for this document. scope for this document.
o How in the world did no reviewers note that "Queries" had been o How in the world did no reviewers note that "Queries" had been
 End of changes. 71 change blocks. 
120 lines changed or deleted 160 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/