< draft-ietf-dnsop-edns-client-subnet-04.txt   draft-ietf-dnsop-edns-client-subnet-05.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: March 28, 2016 D. Lawrence Expires: June 16, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
September 25, 2015 December 14, 2015
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-04 draft-ietf-dnsop-edns-client-subnet-05
Abstract Abstract
This draft defines an EDNS0 extension to carry information about the This document defines an EDNS0 extension to carry information about
network that originated a DNS query, and the network for which the the network that originated a DNS query, and the network for which
subsequent response can be cached. the subsequent response can be cached.
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 March 28, 2016. This Internet-Draft will expire on June 16, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8
7.1. Originating the Option . . . . . . . . . . . . . . . . . 7 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. Forwarders . . . . . . . . . . . . . . . . . . . . . 9 7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 9
7.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10
7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10
7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 11 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12
7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 12
7.3.1. Caching the Response . . . . . . . . . . . . . . . . 12 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 13
7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 13
7.4. Delegations and Negative Answers . . . . . . . . . . . . 14 7.4. Delegations and Negative Answers . . . . . . . . . . . . 14
7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 16
10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 17 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 17
11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 18 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 18
12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 19 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 19
12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 20 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 20
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . 23 16.1. Normative References . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . 24 16.2. Informative References . . . . . . . . . . . . . . . . . 24
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Document History . . . . . . . . . . . . . . . . . . 25 Appendix A. Document History . . . . . . . . . . . . . . . . . . 25
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 Forwarders that are the source of queries. For the Stub Resolvers or Forwarding Resolvers that are the source of
these resolvers, using their own IP address is sufficient for queries. For these resolvers, using their own IP address is
authority servers that tailor responses based upon location of the sufficient for authority servers that tailor responses based upon
querier. 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 a user to configure such a Centralized Resolver varies
but is usually because of some enhanced experience, such as greater but is usually because of some enhanced experience, such as greater
cache security or applying policies regarding where users may cache security or applying policies regarding where users may
connect. (Although political censorship usually comes to mind here, connect. (Although political censorship usually comes to mind here,
the same actions may be used by a parent when setting controls on the same actions may be used by a parent when setting controls on
where a minor may connect.) Similarly, many ISPs and other where a minor may connect.) Similarly, many ISPs and other
organizations use a Centralized Resolver infrastructure that can be organizations use a Centralized Resolver infrastructure that can be
distant from the clients the resolvers serve. These cases all lead distant from the clients the resolvers serve. These cases all lead
to less than desirable responses from topology-sensitive to less than desirable responses from topology-sensitive
Authoritative Nameservers. Authoritative Nameservers.
This draft 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 and authority servers that
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 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 had been At least a dozen different client and server implementations have
written based on the original specification, first known as draft- been written based on earlier versions of this specification. The
vandergaast-edns-client-subnet [1]. The protocol is in active protocol is in active production use today. While the
production use among several major Internet companies, a subset of implementations interoperate, there is varying behavior around edge
which are listed at http://www.afasterinternet.com/participants.htm . cases that were poorly specified. Known incompatibilities are
While they interoperate for the primary goal, they have varying described in this document, and the authors believe that it is better
behaviour around poorly specified edge cases. Known to describe the system as it is working today, even if not everyone
incompatibilities will be described. The authors believe that it is agrees with the details of the original specification (
better to document this system, even if not everyone agrees with the [I-D.vandergaast-edns-client-subnet]). The alternative is an
concept or the details of the original specification, rather than undocumented and proprietary system.
leave it undocumented and proprietary.
A revised proposal to improve upon the minor flaws in this protocol
will be forthcoming to the IETF.
2. Privacy Note 2. Privacy Note
If we were just beginning to design this mechanism, and not If we were just beginning to design this mechanism, and not
documenting existing protocol, it is unlikely that we would have done documenting existing protocol, it is unlikely that we would have done
things exactly this way. things exactly this way.
The IETF is actively working on enhancing DNS privacy [3], and the The IETF is actively working on enhancing DNS privacy
re-injection of metadata has been identified as a problematic design [DPRIVE_Working_Group], and the re-injection of metadata has been
pattern [4]. identified as a problematic design pattern
[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 encourage the deployment of means to allow users to make use of
the opt-out provided. We also recommend that others avoid techniques the opt-out provided. We also recommend that others avoid techniques
that may introduce additional metadata in future work, as it may that may introduce additional metadata in future work, as it may
damage user trust. damage user trust.
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.
Client A Stub Resolver, Forwarder or Recursive Resolver. A client Client: A Stub Resolver, Forwarding Resolver, or Recursive Resolver.
to a Recursive Resolver or a Forwarder. A client to a Recursive Resolver or a Forwarding Resolver.
Server A Forwarder, Recursive Resolver or Authoritative Nameserver. Server: A Forwarding Resolver, 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
Recursive Resolver or a Forwarder. Recursive Resolver or a Forwarding Resolver.
Authoritative Nameserver: A nameserver that has authority over one Authoritative Nameserver: A nameserver that has authority over one
or more DNS zones. These are normally not contacted by Stub or more DNS zones. These are normally not contacted by Stub
Resolver or end user clients directly but by Recursive Resolvers. Resolver or end user clients directly but by Recursive Resolvers.
Described in [RFC1035] Section 6. Described in [RFC1035] Section 6.
Recursive Resolver: A nameserver that is responsible for resolving Recursive Resolver: A nameserver that is responsible for resolving
domain names for clients by following the domain's delegation domain names for clients by following the domain's delegation
chain. Recursive Resolvers frequently use caches to be able to chain. Recursive Resolvers frequently use caches to be able to
respond to client queries quickly. Described in [RFC1035] respond to client queries quickly. Described in [RFC1035]
Section 7. Section 7.
Intermediate Nameserver: Any nameserver (possibly a Recursive Forwarding Resolver: A nameserver that does not do iterative
Resolver) in between the Stub Resolver and the Authoritative resolution itself, but instead passes that responsibility to
Nameserver. another Recursive Resolver, called a "Forwarder" in [RFC2308]
section 1.
Centralized Resolvers: Recursive Resolvers that serve a Intermediate Nameserver: Any nameserver in between the Stub Resolver
and the Authoritative Nameserver, such as a Recursive Resolver or
a Forwarding Resolver.
Centralized Resolvers: Intermediate Nameservers that serve a
topologically diverse network address space. topologically diverse network address space.
Tailored Response: A response from a nameserver that is customized Tailored Response: A response from a nameserver that is customized
for the node that sent the query, often based on performance (i.e. for the node that sent the query, often based on performance (i.e.
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
skipping to change at page 6, line 50 skipping to change at page 7, line 15
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE | 0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH | 2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | FAMILY | 4: | FAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
7: | ADDRESS... / 8: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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 [5]. Address Family Numbers [Address_Family_Numbers].
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 number of significant bits of ADDRESS to be used for the lookup.
responses, it mirrors the same value as in the queries. In 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, number of significant bits of ADDRESS that the response covers.
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 more ADDRESS octets
than are needed, or that has non-zero bits set beyond SOURCE than are needed, or that has non-zero bits set beyond SOURCE
PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a
signal to the developer of the software making the request to fix signal to the developer of the software making the request to fix
skipping to change at page 7, line 47 skipping to change at page 8, line 11
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
option can also be initialized by a Stub Resolver or Forwarder. option can also be initialized by a Stub Resolver or Forwarding
Resolver.
7.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
skipping to change at page 8, line 33 skipping to change at page 8, line 42
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 MUST 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 Forwarding
could possibly run into policy problems with regard to usage Resolver, but could possibly run into policy problems with regard to
agreements between the Recursive Resolver and Authoritative usage agreements between the Recursive Resolver and Authoritative
Namserver. See Section 12.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
the response from a lame delegation, which is the common convention
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.
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 set to
skipping to change at page 9, line 28 skipping to change at page 9, line 30
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,
FAMILY MUST be set to 0. i.e. SOURCE PREFIX-LENGTH is set to 0, FAMILY MUST be set to 0.
7.1.3. Forwarders 7.1.3. Forwarding Resolvers
Forwarders essentially appear to be Stub Resolvers to whatever Forwarding Resolvers essentially appear to be Stub Resolvers to
Recursive Resolver is ultimately handling the query, but look like a whatever Recursive Resolver is ultimately handling the query, but
Recursive Resolver to their client. A Forwarder using this option look like a Recursive Resolver to their client. A Forwarding
MUST prepare it as described in the Section 7.1.1 section above. In Resolver using this option MUST prepare it as described in the
particular, a Forwarder that implements this protocol MUST honor Section 7.1.1 section above. In particular, a Forwarding Resolver
SOURCE PREFIX-LENGTH restrictions indicated in the incoming query that implements this protocol MUST honor SOURCE PREFIX-LENGTH
from its client. See also Section 7.5. restrictions indicated in the incoming query 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 treat it like a Stub
a Stub Resolver, the Forwarder must be prepared for a REFUSED Resolver, the Recursive Resolver's policies regarding incoming
response if the Recursive Resolver does not permit incoming ADDRESS ADDRESS information will apply in the same way. If the Forwarding
information. The Forwarded MUST retry with FAMILY and ADDRESS set to Resover receives a REFUSED response when it sends a query which
0. includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS
set to 0.
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 11, line 6 skipping to change at page 11, line 15
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 draft response, there is an unfortunate ambiguity from the original
as to how SCOPE PREFIX-LENGTH would apply to each individual RRset. specification as to how SCOPE PREFIX-LENGTH would apply to each
For example, multiple types in response to an ANY metaquery could all individual RRset. For example, multiple types in response to an ANY
have different applicable SCOPE PREFIX-LENGTH values, but this metaquery could all have different applicable SCOPE PREFIX-LENGTH
protocol only has the ability to signal one. The response SHOULD values, but this protocol only has the ability to signal one. The
therefore include the longest relevant PREFIX-LENGTH of any RRset in response SHOULD therefore include the longest relevant PREFIX-LENGTH
the answer, which could have the unfortunate side-effect of of any RRset in the answer, which could have the unfortunate side-
redundantly caching some data that could be cached more broadly. For effect of redundantly caching some data that could be cached more
the specific case of a CNAME chain, the Authoritative Nameserver broadly. For the specific case of a CNAME chain, the Authoritative
SHOULD only place the CNAME to have it cached unambiguously Nameserver SHOULD only place the CNAME to have it cached
appropriately. Most modern Recursive Resolvers restart the query unambiguously appropriately. Most modern Recursive Resolvers restart
with the canonical name, so the remainder of the chain is typically the query with the canonical name, so the remainder of the chain is
ignored anyway. For message-focused resolvers, rather than RRset- typically ignored anyway. For message-focused resolvers, rather than
focused ones, this will mean caching the entire CNAME chain at the RRset-focused ones, this will mean caching the entire CNAME chain at
longest PREFIX-LENGTH of any RRset in the chain. 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 If the Authoritative Nameserver operator configures a more specific
(longer prefix length) Tailored Response within a configured less (longer prefix length) Tailored Response within a configured less
specific (shorter prefix length) Tailored Response, then specific (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.
Implementations SHOULD document their chosen behavior. This choice should be documented for the operator, for example in the
user manual.
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 Forwarder which would need the information for could be talking to a Forwaring Resolver which would need the
its own caching. information for its own caching.
If an Intermediate Nameserver receives a response which has a longer If an Intermediate Nameserver receives a response which has a longer
SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in
its query, it SHOULD still provide the result as the answer to the its query, it SHOULD still provide the result as the answer to the
triggering client request even if the client is in a different triggering client request even if the client is in a different
address range. The Intermediate Nameserver MAY instead opt to retry address range. The Intermediate Nameserver MAY instead opt to retry
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
skipping to change at page 12, line 42 skipping to change at page 13, line 5
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 11. this in Section 11.
If a REFUSED response is received from an Authoritative Nameserver,
an ECS-aware resolver MUST retry the query without ECS to distinguish
the authoritative response from a lame delegation, which is the
common convention for a REFUSED status. Similarly, a client of a
Recursive Resolver should retry for REFUSED because it is not
sufficiently clear whether the REFUSED was because of the ECS option
or some other reason.
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 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 7.4. be tied to a network. See more at Section 7.4.
skipping to change at page 14, line 11 skipping to change at page 14, line 24
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.
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 records, the use case that was driving the used for address requests and the positive result in the response's
definition of the protocol. answer section, the use case that was driving the 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
provide customized delegations, it is the resolver that will be using provide customized delegations, it is the resolver that will be using
the answer for its next iterative query. Addresses in the Additional the answer for its next iterative query. Addresses in the Additional
section SHOULD therefore ignore ECS data, and the authority SHOULD section SHOULD therefore ignore ECS data, and the authority SHOULD
return a zero SCOPE PREFIX-LENGTH on delegations. A recursive return a zero SCOPE PREFIX-LENGTH on delegations. A recursive
resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation
as though it were zero. as though it were zero.
skipping to change at page 14, line 47 skipping to change at page 15, line 13
developers should consider when writing new ECS code. developers should consider when writing new ECS code.
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 behaviour on
Intermediate Nameservers. Intermediate Nameservers.
It is important that any Intermediate Nameserver that forwards ECS Any Intermediate Nameserver that forwards ECS options received from
options received from their clients MUST fully implement the caching their clients MUST fully implement the caching behaviour described in
behaviour described in Section 7.3. 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 16, line 20 skipping to change at page 16, line 32
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, Recursive Resolvers sited behind a NAT device SHOULD In other cases, if a Recursive Resolvers knows it is sited behind a
NOT originate ECS options with their external IP address, and instead NAT device, it SHOULD NOT originate ECS options with their external
rely on downstream Intermediate Nameservers to do so. They MAY, IP address, and instead rely on downstream Intermediate Nameservers
however, choose to include the option with their internal address for to do so. They MAY, however, choose to include the option with their
the purposes of signaling a shorter, more anonymous SOURCE PREFIX- internal address for the purposes of signaling a shorter, more
LENGTH. anonymous SOURCE PREFIX-LENGTH.
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
skipping to change at page 19, line 39 skipping to change at page 20, line 4
12.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 (ie, ("public suffic") [Public_Suffix_List] domain servers. These
unlikely to generate different responses based on the address of the domains are delegation-centric and are very unlikely to generate
client. different responses based on the address of the client.
When probing, it is important that several things are probed: support When probing, it is important that several things are probed: support
for ECS, support for EDNS0, support for EDNS0 options, or possibly an for ECS, support for EDNS0, support for EDNS0 options, or possibly an
unreachable Nameserver. Various implementations are known to drop unreachable Nameserver. Various implementations are known to drop
DNS packets with OPT RRs (with or without options), thus several DNS packets with OPT RRs (with or without options), thus several
probes are required to discover what is supported. probes are required to discover what is supported.
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
skipping to change at page 22, line 26 skipping to change at page 22, line 40
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.
14. Contributing Authors 14. Contributing Authors
The below individuals contributed significantly to the draft. The The below individuals contributed significantly to the document. 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
skipping to change at page 23, line 4 skipping to change at page 23, line 20
Akamai Technologies Akamai Technologies
8 Cambridge Ctr 8 Cambridge Ctr
Cambridge MA 02142-1413 Cambridge MA 02142-1413
USA USA
15. 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 Infoblox; Andrew Sullivan from Dyn; John Dickinson from
John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs;
from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin; Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn
and all of the other people that replied to our emails on various Gillmor from the ACLU, and all of the other people that replied to
mailing lists. 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 24, line 31 skipping to change at page 24, line 46
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>.
16.2. Informative References 16.2. Informative References
[Address_Family_Numbers]
"Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>.
[DPRIVE_Working_Group]
"DPRIVE Working Group",
<https://datatracker.ietf.org/wg/dprive/charter/>.
[I-D.hardie-privsec-metadata-insertion]
Hardie, T., "Design considerations for Metadata
Insertion", draft-hardie-privsec-metadata-insertion-00
(work in progress), October 2015.
[I-D.vandergaast-edns-client-subnet]
Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
"Client Subnet in DNS Requests", draft-vandergaast-edns-
client-subnet-02 (work in progress), July 2013.
[Public_Suffix_List]
"Public Suffix List", <https://publicsuffix.org/>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<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>.
16.3. URIs Appendix A. Document History
[1] https://tools.ietf.org/html/draft-vandergaast-edns-client- [RFC Editor: Please delete this section before publication.]
subnet-00
[3] https://datatracker.ietf.org/doc/charter-ietf-dprive/ -05 to -06(?):
[4] https://github.com/IAB-PrivSec-program/draft-iab-privsec- o Minor wording clarifications. (David Kahn Gillmor)
metadata-insertion/blob/master/draft-iab-privsec-metadata-
insertion.md
[5] http://www.iana.org/assignments/address-family-numbers/ -04 to -05:
Appendix A. Document History o Moved comment about retrying for REFUSED to section on "Handling
ECS Responses". (Jinmei)
[RFC Editor: Please delete this section before publication.] o Clarify that a new proposal for an improved ECS protool is
expected.
o "Forwarders" had been used as though they were the source of a
forwarded query rather than the targeted of one; clarified and
defined as "Forwarding Resolver". (Jinmei)
o "representing the leftmost significant bits" => "representing the
leftmost number of significant bits". (Jinmei)
o Minor other clarifying text. (Jinmei)
o Jinmei's affiliation.
-03 to -04: -03 to -04:
o Privacy note per Ted Hardie's suggestion. o Privacy note per Ted Hardie's suggestion.
o MUST use minimum octet length to cover PREFIX bits. o MUST use minimum octet length to cover PREFIX bits.
o Expose note about documenting deployed, if flawed, protocol. o Expose note about documenting deployed, if flawed, protocol.
-02 to -03: -02 to -03:
skipping to change at page 27, line 31 skipping to change at page 28, line 31
length, even if a prior answer indicated that a shorter prefix length, even if a prior answer indicated that a shorter prefix
length was suitable. length was suitable.
o Marked up a few more references. o Marked up a few more references.
o Added a few definitions in the Terminology section, and a few more o Added a few definitions in the Terminology section, and a few more
aesthetic changes in the rest of the document. aesthetic changes in the rest of the document.
A.2. -01 A.2. -01
o Document version number reset from -02 to -00 due to the rename to o Document version number reset from -02 to -00 due to the rename of
ECS. base document.
o Clarified example (dealing with TLDs, and various minor errors). o Clarified example (dealing with TLDs, and various minor errors).
o Referencing RFC5035 instead of RFC1918. o Referencing RFC5035 instead of RFC1918.
o Added a section on probing (and how it should be done) vs. o Added a section on probing (and how it should be done) vs.
whitelisting. whitelisting.
o Moved description on how to forward ECS option in dedicated o Moved description on how to forward ECS option in dedicated
section. section.
 End of changes. 58 change blocks. 
133 lines changed or deleted 185 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/