< draft-ietf-dnsop-edns-client-subnet-00.txt   draft-ietf-dnsop-edns-client-subnet-01.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: May 19, 2015 D. Lawrence Expires: November 27, 2015 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
November 15, 2014 May 26, 2015
Client Subnet in DNS Requests Client Subnet in DNS Querys
draft-ietf-dnsop-edns-client-subnet-00 draft-ietf-dnsop-edns-client-subnet-01
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 reply can be cached. subsequent response can be cached.
IESG Note IESG Note
[RFC Editor: Please remove this note prior to publication ] [RFC Editor: Please remove this note prior to publication ]
This informational document describes an existing, implemented and This informational document describes an existing, implemented and
deployed system. A subset of the operators using this is at deployed system. A subset of the operators using this is at
http://www.afasterinternet.com/participants.htm . The authors believe http://www.afasterinternet.com/participants.htm . The authors believe
that it is better to document this system (even if not everyone that it is better to document this system (even if not everyone
agrees with the concept) than leave it undocumented and proprietary. agrees with the concept) than leave it undocumented and proprietary.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 May 19, 2015. This Internet-Draft will expire on November 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
6.1. Originating the Option . . . . . . . . . . . . . . . . . 7 6.1. Originating the Option . . . . . . . . . . . . . . . . . 7
6.2. Generating a Response . . . . . . . . . . . . . . . . . . 8 6.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 7
6.3. Handling edns-client-subnet Replies and Caching . . . . . 9 6.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 8
6.4. Transitivity . . . . . . . . . . . . . . . . . . . . . . 11 6.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 11
10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 14 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12
10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 14 6.4. Delegations and Negative Answers . . . . . . . . . . . . 13
11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 16 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 16 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 14
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . 20 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Document History . . . . . . . . . . . . . . . . . . 20 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
A.4. -03* . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Document History . . . . . . . . . . . . . . . . . . 23
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many Authoritative Nameservers today return different replies 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 network topology 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 Forwarders that are the source of queries. For
these resolvers, using their own IP address is sufficient for these resolvers, using their own IP address is sufficient for
authority servers that tailor responses based upon location of the authority servers that tailor responses based upon location of the
querier. 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. The cases all lead to distant from the clients the resolvers serve. These cases all lead
less than optimal replies from topology-sensitive Authoritative to less than desirable responses from topology-sensitive
Nameservers. Authoritative Nameservers.
This draft defines an EDNS0 [RFC6891] option to convey network This draft 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 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
written based on the original specification, first known as draft-
vandergaast-edns-client-subnet. While they interoperate for the
primary goal, they have varying behaviour around poorly specified
edge cases. Known incompatibilities will be described.
2. Requirements Notation 2. 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 3. Terminology
ECS EDNS Client Subnet.
Client A Stub Resolver, Forwarder or Recursive Resolver. A client
to a Recursive Resolver or a Forwarder.
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. side as described in [RFC1034] section 5.3.1. A client to a
Recursive Resolver or a Forwarder.
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 clients or more DNS zones. These are normally not contacted by Stub
directly but by Recursive Resolvers. Described in [RFC1035] Resolver or end user clients directly but by Recursive Resolvers.
chapter 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] chapter respond to client queries quickly. Described in [RFC1035]
7. Section 7.
Intermediate Nameserver: Any nameserver (possibly a Recursive Intermediate Nameserver: Any nameserver (possibly a Recursive
Resolver) in between the Stub Resolver and the Authoritative Resolver) in between the Stub Resolver and the Authoritative
Nameserver. Nameserver.
Centralized Resolvers: Recursive Resolvers that serve a Centralized Resolvers: Recursive Resolvers that serve a
topologically diverse network address space. topologically diverse network address space.
Optimized Reply: A reply from a nameserver that is optimized for the Tailored Response: A response from a nameserver that is customized
node that sent the request, normally 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
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 4. 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
Authoritative 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 5, 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. Section 6.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 6.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 reply would also contain an edns-client-subnet option, clearly Its response would contain an edns-client-subnet (ECS) option,
indicating that the server made use of this information, and that the clearly indicating that the server made use of this information, and
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 6.3, Intermediate Nameservers would use this
information to cache the reply. information to cache the response.
Some Intermediate Nameservers may also have to be able to forward Some Intermediate Nameservers may also have to be able to forward ECS
edns-client-subnet queries they receive. This is described in queries they receive. This is described in Section 6.5.
Section 6.4.
The mechanisms provided by edns-client-subnet raise various security The mechanisms provided by ECS raise various security related
related concerns, related to cache growth, the ability to spoof EDNS0 concerns, related to cache growth, the ability to spoof EDNS0
options, and privacy. Section 10 explores various mitigation options, and privacy. Section 10 explores various mitigation
techniques. techniques.
The expectation, however, is that this option will only be used by The expectation, however, is that this option will only be used by
Recursive Resolvers and Authoritative Nameservers that incur Recursive Resolvers and Authoritative Nameservers that incur
geolocation issues. geolocation issues.
Most Recursive Resolvers, Authoritative Nameservers and Stub Most Recursive Resolvers, Authoritative Nameservers and Stub
Resolvers will never know about this option, and will continue Resolvers will never know about this option, and will continue
working as they had been. 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.
and not a cause of concern.
Section 6.1 also provides a mechanism for Stub Resolvers to signal Section 6.1 also provides a mechanism for Stub Resolvers to signal
Recursive Resolvers that they do not want edns-client-subnet Recursive Resolvers that they do not want ECS treatment for specific
treatment for specific requests. queries.
Additionally, operators of Intermediate Nameservers with edns-client- Additionally, operators of Intermediate Nameservers with ECS enabled
subnet enabled are allowed to choose how many bits of the address of are allowed to choose how many bits of the address of received
received queries to forward, or to reduce the number of bits queries to forward, or to reduce the number of bits forwarded for
forwarded for queries already including an edns-client-subnet option. queries already including an ECS option.
5. Option Format 5. Option Format
This draft uses an EDNS0 [RFC6891]) option to include client address This draft uses an EDNS0 [RFC6891]) option to include client address
information in DNS messages. The option is structured as follows: information in DNS messages. The option is structured as follows:
+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 NETMASK | SCOPE NETMASK | 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
7: | ADDRESS... / 7: | ADDRESS... /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for edns-client- o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00
subnet 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 [2].
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 NETMASK, unsigned octet representing the length of the o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
netmask pertaining to the query. In replies, it mirrors the same significant bits of ADDRESS to be used for the lookup. In
value as in the requests. It can be set to 0 to disable client- responses, it mirrors the same value as in the queries.
based lookups, in which case the ADDRESS field MUST be absent.
o SCOPE NETMASK, unsigned octet representing the length of the o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost
netmask pertaining to the reply. In requests, it SHOULD be set to significant bits of ADDRESS that the response covers. In queries,
the longest cacheable length supported by the Intermediate it MUST be set to 0.
Nameserver. For backwards compatibiilty with draft versions of
this specification, in requests it MAY be set to 0 to have the
Authoritative Nameserver treat the longest cacheable length as the
SOURCE NETMASK length. In responses, this field is set by the
Authoritative Nameserver to indicate the coverage of the response.
It might or might not match SOURCE NETMASK; it could be shorter or
longer.
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 in the request to the IPv6 address, depending on FAMILY, truncated to the number of bits
number of bits indicated by the SOURCE NETMASK field, with bits indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to
set to 0 to pad up to the end of the last octet used. (This need pad to the end of the last octet needed. Trailing all-zero octets
not be as many octets as a complete address would take.) In the SHOULD be omitted.
reply, if the SCOPE NETMASK of the request was 0 then ADDRESS must
contain the same octets as in the request. Otherwise, the bits
for ADDRESS will be significant through the maximum of the SOURCE
NETMASK or SCOPE NETMASK, and 0 filled to the end of an octet.
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 6. Protocol Description
6.1. Originating the Option 6.1. Originating the Option
The edns-client-subnet option should generally be added by Recursive The ECS option should generally be added by Recursive Resolvers when
Resolvers when querying other servers, as described in Section 11. querying Authoritative Nameservers, as described in Section 11. The
option can also be initialized by a Stub Resolver or Forwarder.
In this option, the server should include the IP address of the 6.1.1. Recursive Resolvers
client that caused the query to be generated, truncated to the number
of bits specified in the SOURCE NETMASK field.
A Stub Resolver MAY generate DNS queries with an edns-client-subnet The setup of the ECS option in a Recursive Resolver depends on the
option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that client query that triggered the resolution process.
the Recursive Resolver MUST NOT add address information of the client
to its queries. The subsequent Recursive Resolver query to the
Authoritative Nameserver will then either not include an edns-client-
subnet option or MAY optionally include its own address information,
which is what the Authoritative Nameserver will use anyway to
generate the reply in lieu of no option. This allows the answer to
be handled by the same caching mechanism as other requests, with an
explicit indicator of the applicable scope. Subsequent Stub Resolver
requests for /0 can then be answered from this cached response.
The Stub Resolver may also add non-empty edns-client-subnet options In the usual case, where no ECS option was present in the client
to its queries, but Recursive Resolvers are not required to use this query, the Recursive Resolver initializes the option by setting the
information. FAMILY of the client's address. It then uses the value of its
maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For
privacy reasons, and because the whole IP address is rarely required
to determine a tailored response, this length SHOULD be shorter than
the full address, as described in Section 10.
For privacy reasons, and because the whole IP address is rarely If the triggering query included an ECS option itself, it MUST be
required to determine an optimized reply, the ADDRESS field in the examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's
option SHOULD be truncated to a certain number of bits, chosen by the outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of
administrators of the Intermediate Nameserver, as described in the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
Section 10. cacheable prefix length.
If the Stub Resolver requests additional privacy via a SOURCE NETMASK Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the
that is shorter than the maximum cacheable SCOPE NETMASK that the ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits,
Recursive Resolver allows, the Recursive Resolver SHOULD issue the with trailing 0 bits added, if needed, to fill the final octet. The
query with its longer SCOPE NETMASK. total number of octets used should only be enough to cover SOURCE
PREFIX-LENGTH bits, rather than the full width that would normally be
used by addresses in FAMILY.
6.2. Generating a Response FAMILY and ADDRESS information MAY be used from the ECS option
incoming query. Passing the existing address data is supportive of
the Recursive Resolver being used as the target of a Forwarder, but
could possibly run into policy problems with regard to usage
agreements between the Recursive Resolver and Authoritative
Namserver. See Section 11.2 for more discussion on this point. If
the Recursive Resolver will not forward the FAMILY and ADDRESS data
from the incoming ECS option, it SHOULD return a REFUSED response.
[*dcl* -- discussion of existing implementations]
When a query containing an edns-client-subnet option is received, an Subsequent queries to refresh the data MUST, if unrestricted by an
Authoritative Nameserver supporting edns-client-subnet MAY use the incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
address information specified in the option in order to generate an LENGTH that the Recursive Resolver is willing to cache, even if a
optimized reply. previous response indicated that a shorter prefix length was
sufficient.
Authoritative Nameservers that have not implemented or enabled 6.1.2. Stub Resolvers
support for the edns-client-subnet option may safely ignore it within
incoming queries. Per [RFC6891] section 6.1.2, such a server MUST
NOT include an edns-client-subnet option within replies, to indicate
lack of support for the option.
Requests with wrongly formatted options (e.g., wrong size) MUST be A Stub Resolver MAY generate DNS queries with an ECS option set to
rejected and a FORMERR response MUST be returned to the sender, as indicate its own level of privacy via SOURCE PREFIX-LENGTH. An
described by [RFC6891], Transport Considerations. Intermediate Nameserver that receives such a query MUST NOT make
queries that include more bits of client address than in the
originating query.
If the Authoritative Nameserver decides to use information from the A SOURCE PREFIX-LENGTH of 0 means the Recursive Resolver MUST NOT add
edns-client-subnet option to calculate a response, it MUST include address information of the client to its queries. The subsequent
the option in the response to indicate that the information was used Recursive Resolver query to the Authoritative Nameserver will then
and SHOULD be cached accordingly. If the option was not included in either not include an ECS option or MAY optionally include its own
a query, it MUST NOT be included in the response. address information, which is what the Authoritative Nameserver will
almost certainly use to generate any Tailored Response in lieu of an
option. This allows the answer to be handled by the same caching
mechanism as other queries, with an explicit indicator of the
applicable scope. Subsequent Stub Resolver queries for /0 can then
be answered from this cached response.
The FAMILY and SOURCE NETMASK in the response MUST match those in the A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include
request. The first SOURCE NETMASK bits of the ADDRESS in the FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
response MUST match those in the request, even if fewer bits were response if the Intermediate Nameserver that it queries has a policy
used to form the response. Echoing back the address and netmask that denies forwarding of the ADDRESS. If there is no ADDRESS set,
helps to mitigate certain attack vectors, as described in Section 10. FAMILY MUST be set to 0.
The SCOPE NETMASK in the reply indicates the netmask of the network 6.1.3. Forwarders
for which the answer is intended.
A SCOPE NETMASK value longer than the SOURCE NETMASK indicates that Forwarders essentially appear to be Stub Resolvers to whatever
the address and netmask provided in the query was not specific enough Recursive Resolver is ultimately handling the query, but look like a
to select a single, best response. The ADDRESS MUST be extended to Recursive Resolver to their client. A Forwarder using this option
SCOPE NETMASK significant bits to indicate the network for which it MUST prepare it as described in the Section 6.1.1 section above. In
is optimal, but the Recursive Resolver SHOULD still provide the particular, a Forwarder that implements this protocol MUST honor
result as the answer to the triggering client request even if the SOURCE PREFIX-LENGTH restrictions indicated in the incoming query
client is in a different address range. from its client. See also Section 6.5.
Conversely, a shorter SCOPE NETMASK indicates that more bits than Since the Recursive Resolver it contacts will essentially treat it as
necessary were provided, and the answer is suitable for a broader a Stub Resolver, the Forwarder must be prepared for a REFUSED
range of addresses. response if the Recursive Resolver does not permit incoming ADDRESS
information. The Forwarded MUST retry with FAMILY and ADDRESS set to
0.
If a non-zero SCOPE NETMASK was supplied in the request, the SCOPE 6.2. Generating a Response
NETMASK of the response MUST be no longer than the SCOPE NETMASK of
the request.
As not all netblocks are the same size, an Authoritative Nameserver 6.2.1. Authoritative Nameserver
may return different values of SCOPE NETMASK for different networks.
In both cases, the value of the SCOPE NETMASK in the reply has strong When a query containing an ECS option is received, an Authoritative
implications with regard to how the reply will be cached by Nameserver supporting ECS MAY use the address information specified
Intermediate Nameservers, as described in Section 6.3. in the option in order to generate a tailored response.
If the edns-client-subnet option in the request is not used at all, a Authoritative Nameservers that have not implemented or enabled
server supporting edns-client-subnet MUST indicate that no bits of support for the ECS option ought to safely ignore it within incoming
the ADDRESS in the request have been used by specifying a SCOPE queries, per [RFC6891] section 6.1.2. Such a server MUST NOT include
NETMASK of 0, equivalent to the networks 0.0.0.0/0 or ::/0. This an ECS option within replies, to indicate lack of support for it.
could happen, for example, because the reply is invariant across the Implementers of Intermediate Nameservers should be aware, however,
network space. The answer is suitable for all clients for the that some nameservers incorrectly echo back unknown EDNS0 options.
duration of its TTL. In this protocol that should be mostly harmless, as SCOPE PREFIX-
LENGTH should come back as 0, thus marking the response as covering
all networks.
The specific logic that an Authoritative Nameserver uses to choose an A query with a wrongly formatted option (e.g., an unknown FAMILY)
optimized reply is not in the scope of this document. Implementers MUST be rejected and a FORMERR response MUST be returned to the
are encouraged, however, to consider carefully their selection of sender, as described by [RFC6891], Transport Considerations.
SCOPE NETMASK for the reply in the event that an optimal reply cannot
be determined.
6.3. Handling edns-client-subnet Replies and Caching An Authoritative Nameserver that implements this protocol and
receives an ECS option MUST include an ECS option in its response to
indicate that it SHOULD be cached accordingly, regardless of whether
the client information was needed to formulate an answer. (Note that
the [RFC6891] requirement to reserve space for the OPT record could
mean that the answer section of the response will be truncated and
fallback to TCP indicated accordingly.) If an ECS option was not
included in a query, one MUST NOT be included in the response even if
the server is providing a Tailored Response -- presumably based on
the address from which it received the query.
When an Intermediate Nameserver receives a reply containing an edns- The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST
client-subnet option, it will return a reply to its client and SHOULD match those in the query. Echoing back these values helps to
cache the result. mitigate certain attack vectors, as described in Section 10.
If the FAMILY, SOURCE NETMASK, and SOURCE NETMASK bits of ADDRESS in The SCOPE PREFIX-LENGTH in the response indicates the network for
the reply don't match the fields in the corresponding request, the which the answer is intended.
full reply MUST be dropped, as described in Section 10.
In the cache, any resource record in the answer section will be tied A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK indicates that the provided prefix length was not specific enough to
fields, as detailed below. Note that the additional and authority select the most appropriate Tailored Response. Future queries for
sections from a DNS response message are specifically excluded here. the name within the specified network SHOULD use the longer SCOPE
Any information cached from these sections MUST NOT be tied to a PREIX-LENGTH.
network.
If another query is received matching the name and type of an entry Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits
in the cache, the resolver will check whether the FAMILY and ADDRESS than necessary were provided, and the answer is suitable for a
of the client matches one of the networks in the cache for that broader range of addresses. This could be as short as 0, to indicate
entry. that the answer is suitable for all addresses in FAMILY.
If the address of the client is within any of the networks in the As the logical topology of any part of the network with regard to the
cache, then the cached response MUST be returned as usual. If the tailored response can vary, an Authoritative Nameserver may return
address of the client matches multiple networks in the cache, the different values of SCOPE PREFIX-LENGTH for different networks.
entry with the longest SCOPE NETMASK value MUST be returned, as with
most route-matching algorithms.
If the address of the client does not match any network in the cache, The specific logic that an Authoritative Nameserver uses to choose a
then the Recursive Resolver MUST behave as if no match was found and tailored response is not in the scope of this document. Implementers
perform resolution as usual. This is necessary to avoid suboptimal are encouraged, however, to consider carefully their selection of
replies in the cache from being returned to the wrong clients, and to SCOPE PREFIX-LENGTH for the response in the event that the best
avoid a single request coming from a client on a different network tailored response cannot be determined. [Open issue: This seems so
from polluting the cache with a suboptimal reply for all the users of very vague; More text here about possible strategy?]
that resolver.
Note that every time a Recursive Resolver queries an Authoritative If the Authoritative Nameserver operator configures a more specific
Nameserver by forwarding the edns-client-subnet option that it (longer prefix length) Tailored Response within a configured less
received from another client, a short SOURCE NETMASK in the original specific (shorter prefix length) Tailored Response, then
request could cause a suboptimal reply to be returned by the implementations can either:
Authoritative Nameserver.
When the request includes a longer SCOPE NETMASK, the reply returned 1. Deaggregate the shorter prefix response into multiple longer
may still be cached as optimal for the ADDRESS and SCOPE NETMASK of prefix responses, or,
the reply. This might still be suboptimal for the original client.
To avoid this suboptimal reply from being served from cache for other 2. Alert the operator that the order of queries will determine which
clients for which a better reply would be available, the Recursive answers get cached, and either warn and continue or treat this as
Resolver MUST check the SCOPE NETMASK that was returned by the an error and refuse to load the configuration.
Authoritative Nameserver:
o If the SCOPE NETMASK in the reply is longer than the SOURCE Implementations SHOULD document their chosen behavior.
NETMASK, it means that the reply might be suboptimal. A Recursive
Resolver MUST return this entry from cache only to queries that do
not contain or allow a longer SOURCE NETMASK to be forwarded, or
to queries originating from the network covered by the ADDRESS and
SCOPE NETMASK..
o If the SCOPE NETMASK in the reply is shorter than or equal to the 6.2.2. Intermediate Nameserver
SOURCE NETMASK, the reply is optimal, and SHOULD be returned from
cache to any client within the network indicated by ADDRESS and
SCOPE NETMASK.
As another reply is received, the reply will be tied to a different When an Intermediate Nameserver uses ECS, whether it passes an ECS
network. The server SHOULD keep in cache both replies, and return option in its own response to its client is predicated on whether the
the most appropriate one depending on the address of the client. Per client originally included the option. Because a client that did not
standard DNS caching behavior, all records SHOULD be retained until use an ECS option might not be able to understand it, the server MUST
their TTL expires. Subsequent queries to refresh the data should NOT provide one in its response. If the client query did include the
always specify the longest SCOPE NETMASK that the Recursive Resolver option, the server MUST include one in its response, especially as it
is willing to cache, even if previous responses indicated that a could be talking to a Forwarder which would need the information for
shorter netmask was the optimal response. its own caching. [Open issue: if the Forwarder sent 0s for FAMILY
and ADDRESS, how could it take back a response with non-zero FAMILY
and ADDRESS when the spec says this mismatch MUST be dropped?]
Although omitting network-specific caching will significantly If an Intermediate Nameserver receives a response which has a longer
simplify an implementation, the resulting drop in cache hits is very SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in
likely to defeat most latency benefits provided by edns-client- its query, it SHOULD still provide the result as the answer to the
subnet. Therefore, when implementing this option for latency triggering client request even if the client is in a different
purposes, implementing full caching support as described in this address range. The Intermediate Nameserver MAY instead opt to retry
section is STRONGLY RECOMMENDED. with a longer SOURCE PREFIX-LENGTH to get a better reply before
responding to its client, as long as it does not exceed a SOURCE
PREFIX-LENGTH specified in the query that triggered resolution, but
this obviously has implications for the latency of the overall
lookup.
Any reply containing an edns-client-subnet option considered invalid The logic for using the cache to determine whether the Intermediate
should be treated as if no edns-client-subnet option was specified at Nameserver already knows the response to provide to its client is
all. covered in the next section.
Replies coming from servers not supporting edns-client-subnet or 6.3. Handling ECS Responses and Caching
otherwise not containing an edns-client-subnet option SHOULD be
considered as containing a SCOPE NETMASK of 0 (e.g., cache the result
for 0.0.0.0/0 or ::/0) for all the supported families.
In any case, the response from the resolver to the client MUST NOT When an Intermediate Nameserver receives a response containing an ECS
contain the edns-client-subnet option if none was present in the option and without the TC bit set, it SHOULD cache the result based
client's original request. If the original client request contained on the data in the option. If the TC bit was set, the Intermediate
a valid edns-client-subnet option that was used during recursion, the Resolver SHOULD retry the query over TCP to get the complete answer
Recursive Resolver MUST include the edns-client-subnet option from section for caching.
the Authoritative Nameserver response in the response to the client.
Enabling support for edns-client-subnet in a recursive resolver will If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of
ADDRESS in the response don't match the fields in the corresponding
query, the full response MUST be dropped, as described in Section 10.
If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of
this in Section 10.
6.3.1. Caching the Response
In the cache, any resource record in the answer section will be tied
to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX-
LENGTH fields, as limited by the Intermediate Nameserver's own
configuration for maximum cacheable prefix length. Note that the
additional and authority sections from a DNS response message are
specifically excluded here. Any records from these sections MUST NOT
be tied to a network. [Open issue: this conflicts a bit with draft-
kumari-dnsop-multiple-responses, which wants to put data in the
additional section that an authoritative nameserver that does ECS
would probably want to tailor.] See more at Section 6.4.
Records that are cached as /0 because of a query's SOURCE PREFIX-
LENGTH of 0 MUST be distinguished from those that are cached as /0
because of a response's SCOPE PREFIX-LENGTH of 0. The former should
only be used for other /0 queries that the Intermediate Resolver
receives, but the latter is suitable as a response for all networks.
Although omitting network-specific caching will significantly
simplify an implementation, the resulting drop in cache hits is very
likely to defeat most latency benefits provided by ECS. Therefore,
when implementing this option for latency purposes, implementing full
caching support as described in this section is strongly recommended.
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 10 is strongly recommended.
6.4. Transitivity 6.3.2. Answering from Cache
Generally, edns-client-subnet options will only be present in DNS Cache lookups are first done as usual for a DNS query, using the
messages between a Recursive Resolver and an Authoritative query tuple of <name, type, class>. Then the appropriate RRset MUST
Nameserver, i.e., one hop. In certain configurations however, for be chosen based on longest prefix matching. The client address to
example multi-tier nameserver setups, it may be necessary to use for comparison will depend on whether the Intermediate Nameserver
implement transitive behaviour on Intermediate Nameservers. received an ECS option in its client query.
It is important that any Intermediate Nameserver that forwards edns- o If no ECS option was provided, the client's address is used.
client-subnet options received from their clients MUST fully
implement the caching behaviour described in Section 6.3.
Intermediate Nameservers, including Recursive Resolvers, supporting o If there was an ECS option, the ADDRESS from it MAY be used if
edns-client-subnet MUST forward options with SOURCE NETMASK set to 0 local policy allows. Policy can vary depending on the agreements
(i.e., completely anonymized), such an option MUST NOT be replaced the operator of the Intermediate Nameserver has with Authoritative
with an option with more accurate address information. Nameserver operators; see Section 11.2. If policy does not allow,
a REFUSED response must be sent.
An Intermediate Nameserver MAY also forward edns-client-subnet If a matching network is found and the relevant data is unexpired,
options with actual address information. This information MAY match the response is generated as per Section 6.2.
the source IP address of the incoming query, and MAY have more or
less address bits than the Nameserver would normally include in a If no matching network is found, the Intermediate Nameserver MUST
locally originated edns-client-subnet option. perform resolution as usual. This is necessary to avoid Tailored
Responses in the cache from being returned to the wrong clients, and
to avoid a single query coming from a client on a different network
from polluting the cache with a Tailored Response for all the users
of that resolver.
6.4. Delegations and Negative Answers
The prohibition against tying ECS data to records from the Authority
and Additional section left an unfortunate ambiguity in the original
specification, primarily with regard to negative answers. The
expectation of the original authors was that ECS would only really be
used for address records, the use case that was driving the
definition of the protocol.
The delegations case is a bit easier to tease out. In operational
practice, if an authoritative server is using address information to
provide customized delegations, it is the resolver that will be using
the answer for its next iterative query. Addresses in the Additional
section SHOULD therefore ignore ECS data, and the authority SHOULD
return a zero SCOPE PREFIX-LENGTH on delegations. A recursive
resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation
as though it were zero.
For negative answers, some independent implementations of both
resolvers and authorities did not see the section restriction as
necessarily meaning that a given name and type must only have either
positive ECS-tagged answers or a negative answer. They support being
able to tell one part of the network that the data does not exist,
while telling another part of the network that it does.
Several other implementations, however, do not support being able to
mix positive and negative answers, and thus interoperability is a
problem.
This issue is expected to be revisited in a future revision of the
protocol, possibly blessing the mixing of positive and negative
answers. There are implications for cache data structures that
developers should consider when writing new ECS code.
6.5. Transitivity
Generally, ECS options will only be present in DNS messages between a
Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
In certain configurations however, for example multi-tier nameserver
setups, it may be necessary to implement transitive behaviour on
Intermediate Nameservers.
It is important that any Intermediate Nameserver that forwards ECS
options received from their clients MUST fully implement the caching
behaviour described in Section 6.3.
Intermediate Nameservers supporting ECS MUST forward options with
SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized), MUST
forward the query with SOURCE PREFIX-LENGTH set to 0 and MUST NOT be
replaced with an option with more accurate address information.
An Intermediate Nameserver MAY also forward ECS options with actual
address information. This information MAY match the source IP
address of the incoming query, and MAY have more or fewer address
bits than the Nameserver would normally include in a locally
originated ECS option.
If for any reason the Intermediate Nameserver does not want to use If for any reason the Intermediate Nameserver does not want to use
the information in an edns-client-subnet option it receives (too the information in an ECS option it receives (too little address
little address information, network address from a range not information, network address from a range not authorized to use the
authorized to use the server, private/unroutable address space, etc), server, private/unroutable address space, etc), it SHOULD drop the
it SHOULD drop the query and return a REFUSED response. Note again query and return a REFUSED response. Note again that an ECS option
that an edns-client-subnet option with 0 address bits MUST NOT be with 0 address bits MUST NOT be refused.
refused.
Be aware that at least one major existing implementation does not
return REFUSED and instead just process the query as though the
problematic information were not present. This can lead to anomalous
situations, such as a response from the Intermediate Nameserver that
indicates it is tailored for one network (the one passed in the
original query, since ADDRESS must match) when actually it is for
another network (the one which contains the address that the
Intermediate Nameserver saw as making the query).
7. IANA Considerations 7. 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 edns-client-subnet. 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 8. 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 edns-client-subnet option in a DNS query does not containing an ECS option in a DNS query does not change the usage of
change the usage of the resource records and mechanisms used to the resource records and mechanisms used to provide data origin
provide data origin authentication and data integrity to the DNS, as authentication and data integrity to the DNS, as described in
described in [RFC4033], [RFC4034] and [RFC4035]. OPT records are not [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed.
signed.
Use of this option, however, does imply increased DNS traffic between
any given Recursive Resolver and Authoritative Nameserver, which
could be another barrier to further DNSSEC adoption in this area.
9. NAT Considerations 9. NAT Considerations
Special awareness of edns-client-subnet in devices that perform Special awareness of ECS in devices that perform Network Address
Network Address Translation (NAT) as described in [RFC2663] is not Translation (NAT) as described in [RFC2663] is not required; queries
required; queries can be passed through as-is. The client's network can be passed through as-is. The client's network address SHOULD NOT
address SHOULD NOT be added, and existing edns-client-subnet options, be added, and existing ECS options, if present, SHOULD NOT be
if present, SHOULD NOT be modified by NAT devices. modified by NAT devices.
In large-scale global networks behind NAT (but, for example, with a In large-scale global networks behind a NAT device (but for example
Centralized Resolver infrastructure), an internal Intermediate with Centralized Resolver infrastructure), an internal Intermediate
Nameserver might have detailed network layout information, and might 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 edns-client-subnet options. that information when originating ECS options.
In other cases, Recursive Resolvers sited behind a NAT device SHOULD In other cases, Recursive Resolvers sited behind a NAT device SHOULD
NOT originate edns-client-subnet options with their IP address, and NOT originate ECS options with their external IP address, and instead
instead rely on downstream Intermediate Nameservers doing so. They rely on downstream Intermediate Nameservers doing so. They MAY,
MAY, however, choose to include the option with their internal however, choose to include the option with their internal address for
address for the purposes of signaling a shorter, more anonymous the purposes of signaling a shorter, more anonymous SOURCE PREFIX-
SOURCE NETMASK. LENGTH.
If an Authoritative Nameserver on the publicly routed Internet If an Authoritative Nameserver on the publicly routed Internet
receives a request that specifies an ADDRESS in [RFC1918] or receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193]
[RFC4193] private address space, it SHOULD ignore ADDRESS and look up private address space, it SHOULD ignore ADDRESS and look up its
its answer based on the address of the Recursive Resolver. In the answer based on the address of the Recursive Resolver. In the
reply it SHOULD set SCOPE NETMASK to cover all of the relevant response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the
private space. For example, a request for ADDRESS 10.1.2.0 with a relevant private space. For example, a query for ADDRESS 10.1.2.0
SOURCE NETMASK of 24 would get a returned SCOPE NETMASK of 8. The with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX-
Intermediate Nameserver MAY elect to cache the answer under one entry LENGTH of 8. The Intermediate Nameserver MAY elect to cache the
for special-purpose addresses [RFC6890]; see Section 10.3. answer under one entry for special-purpose addresses [RFC6890]; see
Section 10.3.
10. Security Considerations 10. Security Considerations
10.1. Privacy 10.1. Privacy
With the edns-client-subnet option, the network address of the client With the ECS option, the network address of the client that initiated
that initiated the resolution becomes visible to all servers involved the resolution becomes visible to all servers involved in the
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. No recommendation is provided truncating IPv4 addresses to 24 bits. 56 bits are recommended for
for IPv6 at this time, but IPv6 addresses should be similarly IPv6, based on [RFC6177].
truncated in order to not allow unique identification of the client.
When a non-zero SCOPE NETMASK is provided by the Recursive Resolver
that is longer than SOURCE NETMASK, users can often obtain more
optimal mapping if the resolver is well-used. Replies will have
answers optimized up to SCOPE NETMASK bits for a subset of the SOURCE
NETMASK. Subsequent requests within the TTL from clients within the
cached range will be served the optimal answer, while still
preserving privacy of the user.
ISPs will often have more detailed knowledge of their own networks.
That is, they will know if all 24-bit prefixes in a /20 are in the
same area. In those cases, for optimal cache utilization and
improved privacy, the ISP's Recursive Resolver SHOULD truncate IP
addresses in this /20 to just 20 bits, instead of 24 as recommended
above.
Users who wish their full IP address to be hidden can include an ISPs should have more detailed knowledge of their own networks. That
edns-client-subnet option specifying the wildcard address 0.0.0.0/0 is, they might know that all 24-bit prefixes in a /20 are in the same
(i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). area. In those cases, for optimal cache utilization and improved
privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in
this /20 to just 20 bits, instead of 24 as recommended above.
As described in previous sections, this option will be forwarded Users who wish their full IP address to be hidden can include an ECS
across all the Recursive Resolvers supporting edns-client-subnet, option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of
which MUST NOT modify it to include the network address of the 0). As described in previous sections, this option will be forwarded
client. across all the Recursive Resolvers supporting ECS, which MUST NOT
modify it to include the network address of the client.
Note that even without an edns-client-subnet option, any server Note that even without an ECS option, any server queried directly by
queried directly by the user will be able to see the full client IP the user will be able to see the full client IP address. Recursive
address. Recursive Resolvers or Authoritative Nameservers MAY use Resolvers or Authoritative Nameservers MAY use the source IP address
the source IP address of requests to return a cached entry or to of queries to return a cached entry or to generate a Tailored
generate an optimized reply that best matches the request. Response that best matches the query.
10.2. Birthday Attacks 10.2. Birthday Attacks
edns-client-subnet adds information to the DNS question tuple ECS adds information to the DNS query tupe (q-tuple). This allows an
(q-tuple). This allows an attacker to send a caching Intermediate attacker to send a caching Intermediate Nameserver multiple queries
Nameserver multiple queries with spoofed IP addresses either in the with spoofed IP addresses either in the ECS option or as the source
edns-client-subnet option or as the source IP. These queries will IP. These queries will trigger multiple outgoing queries with the
trigger multiple outgoing queries with the same name, type and class, same name, type and class, just different address information in the
just different address information in the edns-client-subnet 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 in sending a matching response (with the higher chance of success to send a matching response with the SCOPE
address 0.0.0.0/0 to get it cached for many hosts). PREFIX-LENGTH set to 0 to get it cached for all hosts.
To counter this, every edns-client-subnet option in a response packet To counter this, every ECS option in a response packet MUST contain
MUST contain the FAMILY and SOURCE NETMASK fields from the the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the
corresponding request, along with identical ADDRESS bits for SOURCE corresponding query. Intermediate Nameservers processing a response
NETMASK length. Intermediate Nameservers processing a response MUST MUST verify that these match, and SHOULD discard the entire response
verify that these match, and MUST discard the entire reply if they do if they do not.
not.
That requirement to discard is "SHOULD" instead of "MUST" because it
stands in opposition to the instruction in Section 6.3 which states
that a response lacking an ECS option should be treated as though it
had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an
attacker does not need to worry about matching the original ECS
option data and just needs to flood back responses that have no ECS
option at all.
This type of attack could be detected in ongoing operations by
marking whether the responding nameserver had previously been sending
ECS option, and/or by taking note of an incoming flood of bogus
responses and flagging the relevant query for re-resolution. This is
more complex than existing nameserver responses to spoof floods, and
would also need to be sensitive to a nameserver legitimately stopping
ECS replies even though it had previously given them.
10.3. Cache Pollution 10.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 edns-client-subnet option, or to send UDP packets information in the ECS option, or to send UDP packets with forged
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.
o reverse engineer the algorithms (or data) used by the o reverse engineer the algorithms (or data) used by the
Authoritative Nameserver to calculate the optimized answer. Authoritative Nameserver to calculate Tailored Responses.
o mount a denial-of-service attack against an Intermediate o mount a denial-of-service attack against an Intermediate
Nameserver, by forcing it to perform many more recursive queries Nameserver, by forcing it to perform many more recursive queries
than it would normally do, due to how caching is handled for than it would normally do, due to how caching is handled for
queries containing the edns-client-subnet option. queries containing the ECS option.
Even without malicious intent, Centralized Resolvers providing Even without malicious intent, Centralized Resolvers providing
answers to clients in multiple networks will need to cache different answers to clients in multiple networks will need to cache different
replies for different networks, putting more memory pressure on the responses for different networks, putting more memory pressure on the
cache. cache.
To mitigate those problems: To mitigate those problems:
o Recursive Resolvers implementing edns-client-subnet should only o Recursive Resolvers implementing ECS should only enable it in
enable it in deployments where it is expected to bring clear deployments where it is expected to bring clear advantages to the
advantages to the end users. For example, when expecting clients end users. For example, when expecting clients from a variety of
from a variety of networks or from a wide geographical area. Due networks or from a wide geographical area. Due to the high cache
to the high cache pressure introduced by edns-client-subnet, the pressure introduced by ECS, the feature SHOULD be disabled in all
feature SHOULD be disabled in all default configurations. default configurations.
o Recursive Resolvers SHOULD limit the number of networks and o Recursive Resolvers SHOULD limit the number of networks and
answers they keep in the cache for a given query. answers they keep in the cache for a given query.
o Recursive Resolvers SHOULD limit the number of total different o Recursive Resolvers SHOULD limit the number of total different
networks that they keep in cache. networks that they keep in cache.
o Recursive Resolvers should never send edns-client-subnet options o Recursive Resolvers MUST never send an ECS option with a SOURCE
with a SCOPE NETMASK that is longer than they are willing to PREFIX-LENGTH providing more bits in the ADDRESS than they are
cache. Similarly, if using the backwards-compatible SCOPE NETMASK willing to cache responses for.
of 0, the request should not set a SOURCE NETMASK of more bits
than they are willing to cache.
o Recursive Resolvers should implement algorithms to improve the o Recursive Resolvers should implement algorithms to improve the
cache hit rate, given the size constraints indicated above. cache hit rate, given the size constraints indicated above.
Recursive Resolvers MAY, for example, decide to discard more Recursive Resolvers MAY, for example, decide to discard more
specific cache entries first. specific cache entries first.
o Authoritative Nameservers and Recursive Resolvers should discard o Authoritative Nameservers and Recursive Resolvers should discard
edns-client-subnet options that are either obviously forged or ECS options that are either obviously forged or otherwise known to
otherwise known to be wrong. They SHOULD at least treat be wrong. They SHOULD at least treat unroutable addresses, such
unroutable addresses, such as some of the address blocks defined as some of the address blocks defined in [RFC6890], as equivalent
in [RFC6890], as equivalent to the Recursive Resolver's own to the Recursive Resolver's own identity. They SHOULD ignore and
identity. They SHOULD ignore and never forward edns-client-subnet never forward ECS options specifying other routable addresses that
options specifying other routable addresses that are known not to are known not to be served by the query source.
be served by the query source.
o Authoritative Nameservers consider the edns-client-subnet option o Authoritative Nameservers consider the ECS option just as a hint
just as a hint to provide better results. They can decide to to provide better results. They can decide to ignore the content
ignore the content of the edns-client-subnet option based on black of the ECS option based on black or white lists, rate limiting
or white lists, rate limiting mechanisms, or any other logic mechanisms, or any other logic implemented in the software.
implemented in the software.
11. Sending the Option 11. 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 edns-client-subnet option in a query. At deciding when to include an ECS option in a query. At this stage,
this stage, it's not clear which strategy is best. it's not clear which strategy is best.
11.1. Probing 11.1. Probing
A Recursive Resolver can send the edns-client-subnet option with A Recursive Resolver can send the ECS option with every outgoing
every outgoing query. However, it is RECOMMENDED that Resolvers query. However, it is RECOMMENDED that Resolvers remember which
remember which Authoritative Nameservers did not return the option Authoritative Nameservers did not return the option with their
with their response, and omit client address information from response, and omit client address information from subsequent queries
subsequent queries to those Nameservers. to those Nameservers.
Additionally, Recursive Resolvers MAY be configured to never send the Additionally, Recursive Resolvers SHOULD be configured to never send
option when querying root, top-level, and effective top-level domain the option when querying root, top-level, and effective top-level
servers. These domains are delegation-centric and are very unlikely domain servers. These domains are delegation-centric and are very
to generate different replies based on the address of the client. unlikely to generate 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 edns-client-subnet, support for EDNS0, support for EDNS0 options, for ECS, support for EDNS0, support for EDNS0 options, or possibly an
or possibly an unreachable Nameserver. Various implementations are unreachable Nameserver. Various implementations are known to drop
known to drop DNS packets with OPT RRs (with or without options), DNS packets with OPT RRs (with or without options), thus several
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 (i.e. daily). Probing, if implemented, MUST be repeated periodically, e.g., daily.
If an Authoritative Nameserver indicates edns-client-subnet support If an Authoritative Nameserver indicates ECS support for one zone, it
for one zone, it is to be expected that the Nameserver supports edns- is to be expected that the Nameserver supports ECS for all of its
client-subnet for all its zones. Likewise, an Authoritative zones. Likewise, an Authoritative Nameserver that uses ECS
Nameserver that uses edns-client-subnet information for one of its information for one of its zones, MUST indicate support for the
zones, MUST indicate support for the option in all its responses. If option in all of its responses to ECS queries. If the option is
the option is supported but not actually used for generating a supported but not actually used for generating a response, its SCOPE
response, its SCOPE NETMASK value SHOULD be set to 0. PREFIX-LENGTH SHOULD be set to 0.
11.2. Whitelist 11.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 edns-client-subnet, and that it will Resolvers will need to use ECS, and that it will generally be enabled
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 decide to use a statically configured an implementation could use a whitelist of Authoritative Namesevers
whitelist of Authoritative Namesevers to send the option to. to send the option to, likely specified by their domain name.
Implementations MAY also allow additionally configuring this based on Implementations MAY also allow additionally configuring this based on
other criteria, such as zone or query type. other criteria, such as zone or query type.
An additional advantage of using a whitelist is that partial client An additional advantage of using a whitelist is that partial client
address information is only disclosed to Nameservers that are known address information is only disclosed to Nameservers that are known
to use the information, improving privacy. to use the information, improving privacy.
A major drawback is scalability. The operator needs to track which A major drawback is scalability. The operator needs to track which
Authoritative Nameservers support edns-client-subnet, making it Authoritative Nameservers support ECS, making it harder for new
harder for new Authoritative Nameservers to start using the option. Authoritative Nameservers to start using the option.
Similarly, Authoritative Nameservers can also use whitelists to limit
the feature to only certain clients. For example, a CDN that does
not want all of their mapping trivially walked might require a legal
agreement with the Recursive Resolver operator, to clearly describe
the acceptable use of the feature.
The maintenance of access control mechanisms is out of scope for this
protocol definition.
12. Example 12. 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 R from IP address IP, asking for recursion. Resolver, RNS, from IP address IP, asking for recursion.
2. RNS, supporting edns-client-subnet, looks up www.example.com in 2. RNS, supporting ECS, looks up www.example.com in its cache. An
its cache. An entry is found neither for www.example.com, nor entry is found neither for www.example.com, nor for example.com.
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 R provides facilities so an administrator can implementation of RNS provides facilities so an administrator
configure RNS not to forward edns-client-subnet in certain can configure it not to forward ECS in certain cases. In
cases. In particular, RNS is configured to not include an edns- particular, RNS is configured to not include an ECS option when
client-subnet option when talking to delegation-centric talking to TLD or root nameservers, as described in Section 6.1.
nameservers, as described in Section 6.1. Thus, no edns-client- Thus, no ECS option is added, and resolution is performed as
subnet option is added, and resolution is performed as usual. usual.
4. RNS now knows the next server to query, Authoritative Nameserver 4. RNS now knows the next server to query: the Authoritative
ANS, responsible for example.com. Nameserver, ANS, responsible for example.com.
5. RNS prepares a new query for www.example.com, including an edns- 5. RNS prepares a new query for www.example.com, including an ECS
client-subnet option with: option with:
* OPTION-CODE, set to 0x00 0x08. * OPTION-CODE, set to 8.
* OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 * OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4
octets plus the 3 octets that will be used for ADDRESS. octets plus the 3 octets that will be used for ADDRESS.
* FAMILY, set to 0x00 0x01 as IP is an IPv4 address. * FAMILY, set to 0x00 0x01 as IP is an IPv4 address.
* SOURCE NETMASK, set to 0x18, as RNS is configured to conceal * SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to
the last 8 bits of every IPv4 address. conceal the last 8 bits of every IPv4 address.
* SCOPE NETMASK, set to 0x1B, as RNS is willing to cache * SCOPE PREFIX-LENGTH, set to 0x00, as specified by this
answers up to a /27. document for all queries.
* ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 * ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24
bits of the IPv4 address. bits of the IPv4 address.
6. The query is sent. Server ANS understands and uses edns-client- 6. The query is sent. ANS understands and uses ECS. It parses the
subnet. It parses the edns-client-subnet option, and generates ECS option, and generates a Tailored Response.
an optimized reply.
7. Due to the internal implementation of ANS, it finds an answer 7. Due its internal implementation, ANS finds a response that is
that is optimal for several /27 ranges within the ADDRESS/SOURCE tailored for the whole /16 of the client that performed the
NETMASK of the request. It chooses one randomly. (Note well, query.
this is just one example of how ANS could pick a suitable
answer. Other selection methods are possible.)
8. The Authoritative Nameserver ANS adds an edns-client-subnet 8. ANS adds an ECS option in the response, containing:
option in the reply, containing:
* OPTION-CODE, set to 0x00 0x08. * OPTION-CODE, set to 8.
* OPTION-LENGTH, set to 0x00 0x08 for the following fixed 4 * OPTION-LENGTH, set to 0x00 0x07.
octets plus the 4 octets that will be used for ADDRESS .
* FAMILY, set to 0x00 0x01, the same as the request. * FAMILY, set to 0x00 0x01.
* SOURCE NETMASK, set to 0x18, copied from the request. * SOURCE PREFIX-LENGTH, set to 0x18, copied from the query.
* SCOPE NETMASK, set to 0x1B, indicating a /27 network. * SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network.
* ADDRESS, set to 0xC0 0x00 0x02 0xE0, copied from the request. * ADDRESS, set to 0xC0 0x00 0x02, copied from the query.
9. RNS receives the reply containing an edns-client-subnet option. 9. RNS receives the response containing an ECS option. It verifies
The resolver verifies that FAMILY, SOURCE NETMASK, and the that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query.
SOURCE NETMASK bits of ADDRESS match the request. If not, the If not, the message is discarded.
message is discarded.
10. The reply is interpreted as usual. Since the reply contains an 10. The response is interpreted as usual. Since the response
edns-client-subnet option, the ADDRESS, SCOPE NETMASK, and contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, and
FAMILY in the response are used to cache the entry. FAMILY in the response are used to cache the entry.
11. RNS sends a response to stub resolver SR, without including an 11. RNS sends a response to stub resolver SR, without including an
edns-client-subnet option. ECS option.
12. RNS receives another request to resolve www.example.com. This 12. RNS receives another query to resolve www.example.com. This
time, a reply is cached. The reply, 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 reply is returned from the cache. network in the cache, then the response is returned from the
Otherwise, another query is performed. If multiple results cache. Otherwise, another query is performed. If multiple
match, the one with the longest SCOPE NETMASK is chosen, as per results match, the one with the longest SCOPE PREFIX-LENGTH is
common best-network match algorithms. chosen, as per common best-network match algorithms.
13. Contributing Authors 13. 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 Los Angeles, CA 90094-2536 USA 12025 Waterfront Drive, Suite 300
Los Angeles CA 90094-2536
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
Akamai Technologies
8 Cambridge Ctr
Cambridge MA 02142-1413
USA
14. Acknowledgements 14. 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, Richard Rabbat from Google, Terry Farmer, Mark Teodoro, Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro,
Edward Lewis, Eric Burger from Neustar, David Ulevitch, Matthew Edward Lewis, and Eric Burger from Neustar; David Ulevitch and
Dempsky from OpenDNS, Patrick W. Gilmore and Jason Moreau from Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from
Akamai, Colm MacCarthaigh, Richard Sheehan and all the other people Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya
that replied to our emails on various mailing lists. Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn;
John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer
from NLnet Labs; Antonio Querubin; and all of the other people that
replied to our emails on various mailing lists.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 20, line 20 skipping to change at page 22, line 51
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013. 6890, April 2013.
[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, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
15.2. Informative References 15.2. Informative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
skipping to change at page 20, line 41 skipping to change at page 23, line 26
2663, August 1999. 2663, August 1999.
15.3. URIs 15.3. URIs
[1] http://www.iana.org/assignments/address-family-numbers/ [1] 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.]
-00 to -01 (IETF)
o <David> Made the document describe how things are actually
implmented now. This makes the document be more of a "this is how
we are doing things, this provides information on that". There
may be a future document that describes additional funcationality.
o NETMASK was not a good desription, changed to PREFIX-LENGTH
(Jinmei, others). Stole most of the definition for prefix length
from RFC4291.
o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include
IPv6 (Tatuya Jinmei)
o Comment that ECS cannot be used to hand NXDOMAIN to some clients
and not others, primarily because of interoperability issues.
(Tatuya Jinmei)
o Added text explaining that implmentations need to document thier
behavior with overlapping networks.
o Soften "optimized reply" language. (Andrew Sullivan).
o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0)
o Some more grammar / working cleanups.
o Replaced a whole heap of occurances of "edns-client-subnet" with
"ECS" for readability. (John Dickinson)
o More clearly describe the process from the point of view of each
type of nameserver. (John Dickinson)
o Birthday attack still possible if attacker floods with ECS-less
responses. (Yuri Schaeffer)
o Added some open issues directly to the text.
A.1. -00 A.1. -00
o Document moved to experimental track, added experiment description o Document moved to experimental track, added experiment description
in header with details in a new section. in header with details in a new section.
o Specifically note that edns-client-subnet applies to the answer o Specifically note that ECS applies to the answer section only.
section only.
o Warn that caching based on edns-client-subnet is optional but very o Warn that caching based on ECS is optional but very important for
important for performance reasons. performance reasons.
o Updated NAT section. o Updated NAT section.
o Added recommendation to not use the default /24 recommendation for o Added recommendation to not use the default /24 recommendation for
the source netmask field if more detailed information about the the source prefix-length field if more detailed information about
network is available. the network is available.
o Rewritten problem statement to be more clear about the goal of o Rewritten problem statement to be more clear about the goal of ECS
edns-client-subnet and the fact that it's entirely optional. and the fact that it's entirely optional.
o Wire format changed to include the original address and netmask in o Wire format changed to include the original address and prefix
responses in defence against birthday attacks. length in responses in defence against birthday attacks.
o Security considerations now includes a section about birthday o Security considerations now includes a section about birthday
attacks. attacks.
o Renamed edns-client-ip in edns-client-subnet, following o Renamed edns-client-ip in ECS, following suggestions on the
suggestions on the mailing list. mailing list.
o Clarified behavior of resolvers when presented with an invalid o Clarified behavior of resolvers when presented with an invalid ECS
edns-client-subnet option. option.
o Fully take multi-tier DNS setups in mind and be more clear about o Fully take multi-tier DNS setups in mind and be more clear about
where the option should be originated. where the option should be originated.
o A note on Authoritative Nameservers receiving queries that specify
private address space.
o A note to always ask for the longest acceptable SOURCE prefix
length, even if a prior answer indicated that a shorter prefix
length was suitable.
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 to
edns-client-subnet. ECS.
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 edns-client-subnet option in o Moved description on how to forward ECS option in dedicated
dedicated section. section.
o Queries with wrongly formatted edns-client-subnet options should o Queries with wrongly formatted ECS options should now be rejected
now be rejected with FORMERR. with FORMERR.
o Added an "Overview" section, providing an introduction to the o Added an "Overview" section, providing an introduction to the
document. document.
o Intermediate Nameservers can now remove an edns-client-subnet o Intermediate Nameservers can now remove an ECS option, or reduce
option, or reduce the SOURCE NETMASK to increase privacy. the SOURCE PREFIX-LENGTH to increase privacy.
o Added a reference to DoS attacks in the Security section. o Added a reference to DoS attacks in the Security section.
o Don't use "network range", as it seems to have different meaning o Don't use "network range", as it seems to have different meaning
in other contexts, and turned out to be confusing. in other contexts, and turned out to be confusing.
o Use shorter and longer netmasks, rather than higher or lower. Add o Use shorter and longer prefix lengths, rather than higher or
a better explanation in the format section. lower. Add a better explanation in the format section.
o Minor corrections in various other sections. o Minor corrections in various other sections.
A.3. -02 A.3. -02
o Added IANA-assigned option code. o Added IANA-assigned option code.
A.4. -03*
o [*] There was no -03 version of the draft; these changes, however,
were made after -02.
o Allow non-zero SCOPE NETMASK for Recursive Resolvers to indicate
their maximum cacheable mask length, and updated the example
accordingly.
o A note on Authoritative Nameservers receiving requests that
specify private address space.
o A note to always ask for the longest acceptable SCOPE NETMASK,
even if a prior answer indicated that a shorter netmask was
optimal.
o Marked up a couple of references.
o Minor grammatical consistency edits.
Authors' Addresses Authors' Addresses
Carlo Contavalli Carlo Contavalli
Google Google
1600 Amphitheater Parkway 1600 Amphitheater Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: ccontavalli@google.com Email: ccontavalli@google.com
Wilmer van der Gaast Wilmer van der Gaast
Google Google
Belgrave House, 76 Buckingham Palace Road Belgrave House, 76 Buckingham Palace Road
London SW1W 9TQ London SW1W 9TQ
UK UK
Email: wilmer@google.com Email: wilmer@google.com
David C Lawrence David C Lawrence
Akamai Technologies Akamai Technologies
 End of changes. 150 change blocks. 
509 lines changed or deleted 667 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/