< draft-ietf-dnsop-edns-client-subnet-01.txt   draft-ietf-dnsop-edns-client-subnet-02.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: November 27, 2015 D. Lawrence Expires: January 7, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
May 26, 2015 July 6, 2015
Client Subnet in DNS Querys Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-01 draft-ietf-dnsop-edns-client-subnet-02
Abstract Abstract
This draft defines an EDNS0 extension to carry information about the This draft defines an EDNS0 extension to carry information about the
network that originated a DNS query, and the network for which the network that originated a DNS query, and the network for which the
subsequent response can be cached. subsequent response can be cached.
IESG Note IESG Note
[RFC Editor: Please remove this note prior to publication ] [RFC Editor: Please remove this note prior to publication ]
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 November 27, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 7 6.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 7
6.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 8 6.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 8
6.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9 6.1.3. Forwarders . . . . . . . . . . . . . . . . . . . . . 9
6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9 6.2. Generating a Response . . . . . . . . . . . . . . . . . . 9
6.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9 6.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 9
6.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 10 6.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 11
6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11 6.3. Handling ECS Responses and Caching . . . . . . . . . . . 11
6.3.1. Caching the Response . . . . . . . . . . . . . . . . 11 6.3.1. Caching the Response . . . . . . . . . . . . . . . . 12
6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12 6.3.2. Answering from Cache . . . . . . . . . . . . . . . . 12
6.4. Delegations and Negative Answers . . . . . . . . . . . . 13 6.4. Delegations and Negative Answers . . . . . . . . . . . . 13
6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 14 8. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 15
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16 10.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 16
10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17 10.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 17
11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18 11. Sending the Option . . . . . . . . . . . . . . . . . . . . . 18
11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 23
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Document History . . . . . . . . . . . . . . . . . . 23 Appendix A. Document History . . . . . . . . . . . . . . . . . . 23
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many Authoritative Nameservers today return different responses based Many Authoritative Nameservers today return different responses based
on the perceived topological location of the user. These servers use on the perceived topological location of the user. These servers use
the IP address of the incoming query to identify that location. the IP address of the incoming query to identify that location.
Since most queries come from intermediate Recursive Resolvers, the Since most queries come from intermediate Recursive Resolvers, the
source address is that of the Recursive Resolver rather than of the source address is that of the Recursive Resolver rather than of the
query originator. query originator.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
clearly indicating that the server made use of this information, and clearly indicating that the server made use of this information, and
that the answer is tied to the network of the client. that the answer is tied to the network of the client.
As described in Section 6.3, Intermediate Nameservers would use this As described in Section 6.3, Intermediate Nameservers would use this
information to cache the response. information to cache the response.
Some Intermediate Nameservers may also have to be able to forward ECS Some Intermediate Nameservers may also have to be able to forward ECS
queries they receive. This is described in Section 6.5. queries they receive. This is described in Section 6.5.
The mechanisms provided by ECS raise various security related The mechanisms provided by ECS raise various security related
concerns, related to cache growth, the ability to spoof EDNS0 concerns related to cache growth, the ability to spoof EDNS0 options,
options, and privacy. Section 10 explores various mitigation and privacy. Section 10 explores various mitigation techniques.
techniques.
The expectation, however, is that this option will only be used by
Recursive Resolvers and Authoritative Nameservers that incur
geolocation issues.
Most Recursive Resolvers, Authoritative Nameservers and Stub The expectation, however, is that this option will primarily be used
Resolvers will never know about this option, and will continue between Recursive Resolvers and Authoritative Nameservers that are
working as they had been. sensitive to network location issues. Most Recursive Resolvers,
Authoritative Nameservers and Stub Resolvers will never need to know
about this option, and will continue working as they had been.
Failure to support this option or its improper handling will, at Failure to support this option or its improper handling will, at
worst, cause suboptimal identification of client location, which is a worst, cause suboptimal identification of client location, which is a
common occurrence in current content delivery network (CDN) setups. common occurrence in current content delivery network (CDN) setups.
Section 6.1 also provides a mechanism for Stub Resolvers to signal Section 6.1 also provides a mechanism for Stub Resolvers to signal
Recursive Resolvers that they do not want ECS treatment for specific Recursive Resolvers that they do not want ECS treatment for specific
queries. queries.
Additionally, operators of Intermediate Nameservers with ECS enabled Additionally, operators of Intermediate Nameservers with ECS enabled
are allowed to choose how many bits of the address of received are allowed to choose how many bits of the address of received
queries to forward, or to reduce the number of bits forwarded for queries to forward, or to reduce the number of bits forwarded for
queries already including an ECS option. queries already including an ECS option.
5. Option Format 5. Option Format
This draft uses an EDNS0 [RFC6891]) option to include client address This protocol uses an EDNS0 [RFC6891]) option to include client
information in DNS messages. The option is structured as follows: address 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 PREFIX-LENGTH | SCOPE PREFIX-LENGTH | 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
skipping to change at page 8, line 12 skipping to change at page 8, line 7
the incoming query's SOURCE PREFIX-LENGTH or the server's maximum the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
cacheable prefix length. cacheable prefix length.
Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and the
ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits, ADDRESS is then added up to the SOURCE PREFIX-LENGTH number of bits,
with trailing 0 bits added, if needed, to fill the final octet. The with trailing 0 bits added, if needed, to fill the final octet. The
total number of octets used should only be enough to cover SOURCE total number of octets used should only be enough to cover SOURCE
PREFIX-LENGTH bits, rather than the full width that would normally be PREFIX-LENGTH bits, rather than the full width that would normally be
used by addresses in FAMILY. used by addresses in FAMILY.
FAMILY and ADDRESS information MAY be used from the ECS option FAMILY and ADDRESS information MAY be used from the ECS option in the
incoming query. Passing the existing address data is supportive of incoming query. Passing the existing address data is supportive of
the Recursive Resolver being used as the target of a Forwarder, but the Recursive Resolver being used as the target of a Forwarder, but
could possibly run into policy problems with regard to usage could possibly run into policy problems with regard to usage
agreements between the Recursive Resolver and Authoritative agreements between the Recursive Resolver and Authoritative
Namserver. See Section 11.2 for more discussion on this point. If Namserver. See Section 11.2 for more discussion on this point. If
the Recursive Resolver will not forward the FAMILY and ADDRESS data the Recursive Resolver will not forward the FAMILY and ADDRESS data
from the incoming ECS option, it SHOULD return a REFUSED response. from the incoming ECS option, it SHOULD return a REFUSED response.
[*dcl* -- discussion of existing implementations] An ECS-aware resolver MUST retry the query without ECS to distinguish
the response from a lame delegation, which is the common convention
for a REFUSED status.
Subsequent queries to refresh the data MUST, if unrestricted by an Subsequent queries to refresh the data MUST, if unrestricted by an
incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
LENGTH that the Recursive Resolver is willing to cache, even if a LENGTH that the Recursive Resolver is willing to cache, even if a
previous response indicated that a shorter prefix length was previous response indicated that a shorter prefix length was
sufficient. sufficient.
6.1.2. Stub Resolvers 6.1.2. Stub Resolvers
A Stub Resolver MAY generate DNS queries with an ECS option set to A Stub Resolver MAY generate DNS queries with an ECS option set to
skipping to change at page 10, line 6 skipping to change at page 10, line 6
indicate that it SHOULD be cached accordingly, regardless of whether indicate that it SHOULD be cached accordingly, regardless of whether
the client information was needed to formulate an answer. (Note that the client information was needed to formulate an answer. (Note that
the [RFC6891] requirement to reserve space for the OPT record could the [RFC6891] requirement to reserve space for the OPT record could
mean that the answer section of the response will be truncated and mean that the answer section of the response will be truncated and
fallback to TCP indicated accordingly.) If an ECS option was not fallback to TCP indicated accordingly.) If an ECS option was not
included in a query, one MUST NOT be included in the response even if included in a query, one MUST NOT be included in the response even if
the server is providing a Tailored Response -- presumably based on the server is providing a Tailored Response -- presumably based on
the address from which it received the query. the address from which it received the query.
The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST The FAMILY, SOURCE PREFIX-LENGTH and ADDRESS in the response MUST
match those in the query. Echoing back these values helps to match those in the query, unless the query specified only the SOURCE
mitigate certain attack vectors, as described in Section 10. PREFIX-LENGTH for privacy (with FAMILY and ADDRESS set to 0).
Echoing back these values helps to mitigate certain attack vectors,
as described in Section 10.
The SCOPE PREFIX-LENGTH in the response indicates the network for The SCOPE PREFIX-LENGTH in the response indicates the network for
which the answer is intended. which the answer is intended.
A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
indicates that the provided prefix length was not specific enough to indicates that the provided prefix length was not specific enough to
select the most appropriate Tailored Response. Future queries for select the most appropriate Tailored Response. Future queries for
the name within the specified network SHOULD use the longer SCOPE the name within the specified network SHOULD use the longer SCOPE
PREIX-LENGTH. PREFIX-LENGTH.
Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits
than necessary were provided, and the answer is suitable for a than necessary were provided, and the answer is suitable for a
broader range of addresses. This could be as short as 0, to indicate broader range of addresses. This could be as short as 0, to indicate
that the answer is suitable for all addresses in FAMILY. that the answer is suitable for all addresses in FAMILY.
As the logical topology of any part of the network with regard to the As the logical topology of any part of the network with regard to the
tailored response can vary, an Authoritative Nameserver may return tailored response can vary, an Authoritative Nameserver may return
different values of SCOPE PREFIX-LENGTH for different networks. different values of SCOPE PREFIX-LENGTH for different networks.
Since some queries can result in multiple RRsets being added to the
response, there is an unfortunate ambiguity from the original draft
as to how SCOPE PREFIX-LENGTH would apply to each individual RRset.
For example, multiple types in response to an ANY metaquery could all
have different applicable SCOPE PREFIX-LENGTH values, but this
protocol only has the ability to signal one. The response SHOULD
therefore include the longest relevant PREFIX-LENGTH of any RRset in
the answer, which could have the unfortunate side-effect of
redundantly caching some data that could be cached more broadly. For
the specific case of a CNAME chain, the Authoritative Nameserver
SHOULD only place the CNAME to have it cached unambiguously
appropriately. Most modern Recursive Resolvers restart the query
with the canonical name, so the remainder of the chain is typically
ignored anyway. For message-focused resolvers, rather than RRset-
focused ones, this will mean caching the entire CNAME chain at the
longest PREFIX-LENGTH of any RRset in the chain.
The specific logic that an Authoritative Nameserver uses to choose a The specific logic that an Authoritative Nameserver uses to choose a
tailored response is not in the scope of this document. Implementers tailored response is not in the scope of this document. Implementers
are encouraged, however, to consider carefully their selection of are encouraged, however, to consider carefully their selection of
SCOPE PREFIX-LENGTH for the response in the event that the best SCOPE PREFIX-LENGTH for the response in the event that the best
tailored response cannot be determined. [Open issue: This seems so tailored response cannot be determined, and what the implications
very vague; More text here about possible strategy?] would be over the life of the TTL.
If the Authoritative Nameserver operator configures a more specific If the Authoritative Nameserver operator configures a more specific
(longer prefix length) Tailored Response within a configured less (longer prefix length) Tailored Response within a configured less
specific (shorter prefix length) Tailored Response, then specific (shorter prefix length) Tailored Response, then
implementations can either: implementations can either:
1. Deaggregate the shorter prefix response into multiple longer 1. Deaggregate the shorter prefix response into multiple longer
prefix responses, or, prefix responses, or,
2. Alert the operator that the order of queries will determine which 2. Alert the operator that the order of queries will determine which
skipping to change at page 11, line 8 skipping to change at page 11, line 28
6.2.2. Intermediate Nameserver 6.2.2. Intermediate Nameserver
When an Intermediate Nameserver uses ECS, whether it passes an ECS When an Intermediate Nameserver uses ECS, whether it passes an ECS
option in its own response to its client is predicated on whether the option in its own response to its client is predicated on whether the
client originally included the option. Because a client that did not client originally included the option. Because a client that did not
use an ECS option might not be able to understand it, the server MUST use an ECS option might not be able to understand it, the server MUST
NOT provide one in its response. If the client query did include the NOT provide one in its response. If the client query did include the
option, the server MUST include one in its response, especially as it option, the server MUST include one in its response, especially as it
could be talking to a Forwarder which would need the information for could be talking to a Forwarder which would need the information for
its own caching. [Open issue: if the Forwarder sent 0s for FAMILY its own caching.
and ADDRESS, how could it take back a response with non-zero FAMILY
and ADDRESS when the spec says this mismatch MUST be dropped?]
If an Intermediate Nameserver receives a response which has a longer If an Intermediate Nameserver receives a response which has a longer
SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in
its query, it SHOULD still provide the result as the answer to the its query, it SHOULD still provide the result as the answer to the
triggering client request even if the client is in a different triggering client request even if the client is in a different
address range. The Intermediate Nameserver MAY instead opt to retry address range. The Intermediate Nameserver MAY instead opt to retry
with a longer SOURCE PREFIX-LENGTH to get a better reply before with a longer SOURCE PREFIX-LENGTH to get a better reply before
responding to its client, as long as it does not exceed a SOURCE responding to its client, as long as it does not exceed a SOURCE
PREFIX-LENGTH specified in the query that triggered resolution, but PREFIX-LENGTH specified in the query that triggered resolution, but
this obviously has implications for the latency of the overall this obviously has implications for the latency of the overall
skipping to change at page 11, line 36 skipping to change at page 12, line 6
6.3. Handling ECS Responses and Caching 6.3. Handling ECS Responses and Caching
When an Intermediate Nameserver receives a response containing an ECS When an Intermediate Nameserver receives a response containing an ECS
option and without the TC bit set, it SHOULD cache the result based option and without the TC bit set, it SHOULD cache the result based
on the data in the option. If the TC bit was set, the Intermediate on the data in the option. If the TC bit was set, the Intermediate
Resolver SHOULD retry the query over TCP to get the complete answer Resolver SHOULD retry the query over TCP to get the complete answer
section for caching. section for caching.
If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of If the FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of
ADDRESS in the response don't match the fields in the corresponding ADDRESS in the response don't match the non-zero fields in the
query, the full response MUST be dropped, as described in Section 10. corresponding query, the full response MUST be dropped, as described
in Section 10. For a response to query which specified only the
SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS
fields should contain the appropriate non-zero information for
caching.
If no ECS option is contained in the response, the Intermediate If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of addresses. See further discussion on the security implications of
this in Section 10. this in Section 10.
6.3.1. Caching the Response 6.3.1. Caching the Response
In the cache, any resource record in the answer section will be tied In the cache, all resource records in the answer section MUST be tied
to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX-
LENGTH fields, as limited by the Intermediate Nameserver's own LENGTH fields, as limited by the Intermediate Nameserver's own
configuration for maximum cacheable prefix length. Note that the configuration for maximum cacheable prefix length. Note that the
additional and authority sections from a DNS response message are additional and authority sections from a DNS response message are
specifically excluded here. Any records from these sections MUST NOT specifically excluded here. Any records from these sections MUST NOT
be tied to a network. [Open issue: this conflicts a bit with draft- be tied to a network. See more at Section 6.4.
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- Records that are cached as /0 because of a query's SOURCE PREFIX-
LENGTH of 0 MUST be distinguished from those that are cached as /0 LENGTH of 0 MUST be distinguished from those that are cached as /0
because of a response's SCOPE PREFIX-LENGTH of 0. The former should because of a response's SCOPE PREFIX-LENGTH of 0. The former should
only be used for other /0 queries that the Intermediate Resolver only be used for other /0 queries that the Intermediate Resolver
receives, but the latter is suitable as a response for all networks. receives, but the latter is suitable as a response for all networks.
Although omitting network-specific caching will significantly Although omitting network-specific caching will significantly
simplify an implementation, the resulting drop in cache hits is very simplify an implementation, the resulting drop in cache hits is very
likely to defeat most latency benefits provided by ECS. Therefore, likely to defeat most latency benefits provided by ECS. Therefore,
skipping to change at page 14, line 6 skipping to change at page 14, line 27
Recursive Resolver and an Authoritative Nameserver, i.e., one hop. Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
In certain configurations however, for example multi-tier nameserver In certain configurations however, for example multi-tier nameserver
setups, it may be necessary to implement transitive behaviour on setups, it may be necessary to implement transitive behaviour on
Intermediate Nameservers. Intermediate Nameservers.
It is important that any Intermediate Nameserver that forwards ECS It is important that any Intermediate Nameserver that forwards ECS
options received from their clients MUST fully implement the caching options received from their clients MUST fully implement the caching
behaviour described in Section 6.3. behaviour described in Section 6.3.
Intermediate Nameservers supporting ECS MUST forward options with Intermediate Nameservers supporting ECS MUST forward options with
SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized), MUST SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such
forward the query with SOURCE PREFIX-LENGTH set to 0 and MUST NOT be options MUST NOT be replaced with more accurate address information.
replaced with an option with more accurate address information.
An Intermediate Nameserver MAY also forward ECS options with actual An Intermediate Nameserver MAY also forward ECS options with actual
address information. This information MAY match the source IP address information. This information MAY match the source IP
address of the incoming query, and MAY have more or fewer address address of the incoming query, and MAY have more or fewer address
bits than the Nameserver would normally include in a locally bits than the Nameserver would normally include in a locally
originated ECS option. originated ECS option.
If for any reason the Intermediate Nameserver does not want to use If for any reason the Intermediate Nameserver does not want to use
the information in an ECS option it receives (too little address the information in an ECS option it receives (too little address
information, network address from a range not authorized to use the information, network address from a range not authorized to use the
server, private/unroutable address space, etc), it SHOULD drop the server, private/unroutable address space, etc), it SHOULD drop the
query and return a REFUSED response. Note again that an ECS option query and return a REFUSED response. Note again that a query MUST
with 0 address bits MUST NOT be refused. NOT be refused solely because it provides 0 address bits.
Be aware that at least one major existing implementation does not Be aware that at least one major existing implementation does not
return REFUSED and instead just process the query as though the return REFUSED and instead just process the query as though the
problematic information were not present. This can lead to anomalous problematic information were not present. This can lead to anomalous
situations, such as a response from the Intermediate Nameserver that situations, such as a response from the Intermediate Nameserver that
indicates it is tailored for one network (the one passed in the indicates it is tailored for one network (the one passed in the
original query, since ADDRESS must match) when actually it is for original query, since ADDRESS must match) when actually it is for
another network (the one which contains the address that the another network (the one which contains the address that the
Intermediate Nameserver saw as making the query). Intermediate Nameserver saw as making the query).
skipping to change at page 15, line 22 skipping to change at page 15, line 42
In large-scale global networks behind a NAT device (but for example In large-scale global networks behind a NAT device (but for example
with Centralized Resolver infrastructure), an internal Intermediate with Centralized Resolver infrastructure), an internal Intermediate
Nameserver might have detailed network layout information, and may Nameserver might have detailed network layout information, and may
know which external subnets are used for egress traffic by each know which external subnets are used for egress traffic by each
internal network. In such cases, the Intermediate Nameserver MAY use internal network. In such cases, the Intermediate Nameserver MAY use
that information when originating ECS options. that information when originating ECS options.
In other cases, Recursive Resolvers sited behind a NAT device SHOULD In other cases, Recursive Resolvers sited behind a NAT device SHOULD
NOT originate ECS options with their external IP address, and instead NOT originate ECS options with their external IP address, and instead
rely on downstream Intermediate Nameservers doing so. They MAY, rely on downstream Intermediate Nameservers to do so. They MAY,
however, choose to include the option with their internal address for however, choose to include the option with their internal address for
the purposes of signaling a shorter, more anonymous SOURCE PREFIX- the purposes of signaling a shorter, more anonymous SOURCE PREFIX-
LENGTH. LENGTH.
If an Authoritative Nameserver on the publicly routed Internet If an Authoritative Nameserver on the publicly routed Internet
receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193] receives a query that specifies an ADDRESS in [RFC1918] or [RFC4193]
private address space, it SHOULD ignore ADDRESS and look up its private address space, it SHOULD ignore ADDRESS and look up its
answer based on the address of the Recursive Resolver. In the answer based on the address of the Recursive Resolver. In the
response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the response it SHOULD set SCOPE PREFIX-LENGTH to cover all of the
relevant private space. For example, a query for ADDRESS 10.1.2.0 relevant private space. For example, a query for ADDRESS 10.1.2.0
skipping to change at page 16, line 36 skipping to change at page 17, line 9
attacker to send a caching Intermediate Nameserver multiple queries attacker to send a caching Intermediate Nameserver multiple queries
with spoofed IP addresses either in the ECS option or as the source with spoofed IP addresses either in the ECS option or as the source
IP. These queries will trigger multiple outgoing queries with the IP. These queries will trigger multiple outgoing queries with the
same name, type and class, just different address information in the same name, type and class, just different address information in the
ECS option. ECS option.
With multiple queries for the same name in flight, the attacker has a With multiple queries for the same name in flight, the attacker has a
higher chance of success to send a matching response with the SCOPE higher chance of success to send a matching response with the SCOPE
PREFIX-LENGTH set to 0 to get it cached for all hosts. PREFIX-LENGTH set to 0 to get it cached for all hosts.
To counter this, every ECS option in a response packet MUST contain To counter this, the ECS option in a response packet MUST contain the
the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the full FAMILY, ADDRESS and SOURCE PREFIX-LENGTH fields from the
corresponding query. Intermediate Nameservers processing a response corresponding query. Intermediate Nameservers processing a response
MUST verify that these match, and SHOULD discard the entire response MUST verify that these match, and SHOULD discard the entire response
if they do not. if they do not.
That requirement to discard is "SHOULD" instead of "MUST" because it That requirement to discard is "SHOULD" instead of "MUST" because it
stands in opposition to the instruction in Section 6.3 which states stands in opposition to the instruction in Section 6.3 which states
that a response lacking an ECS option should be treated as though it that a response lacking an ECS option should be treated as though it
had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an had one of SCOPE PREFIX-LENGTH of 0. If that is always true, then an
attacker does not need to worry about matching the original ECS attacker does not need to worry about matching the original ECS
option data and just needs to flood back responses that have no ECS option data and just needs to flood back responses that have no ECS
skipping to change at page 17, line 43 skipping to change at page 18, line 17
To mitigate those problems: To mitigate those problems:
o Recursive Resolvers implementing ECS should only enable it in o Recursive Resolvers implementing ECS should only enable it in
deployments where it is expected to bring clear advantages to the deployments where it is expected to bring clear advantages to the
end users. For example, when expecting clients from a variety of end users. For example, when expecting clients from a variety of
networks or from a wide geographical area. Due to the high cache networks or from a wide geographical area. Due to the high cache
pressure introduced by ECS, the feature SHOULD be disabled in all pressure introduced by ECS, the feature SHOULD be disabled in all
default configurations. default configurations.
o Recursive Resolvers SHOULD limit the number of networks and o Recursive Resolvers SHOULD limit the number of networks and
answers they keep in the cache for a given query. answers they keep in the cache for any given query.
o Recursive Resolvers SHOULD limit the number of total different o Recursive Resolvers SHOULD limit the number of total different
networks that they keep in cache. networks that they keep in cache.
o Recursive Resolvers MUST never send an ECS option with a SOURCE o Recursive Resolvers MUST never send an ECS option with a SOURCE
PREFIX-LENGTH providing more bits in the ADDRESS than they are PREFIX-LENGTH providing more bits in the ADDRESS than they are
willing to cache responses for. willing to cache responses for.
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.
skipping to change at page 19, line 7 skipping to change at page 19, line 32
DNS packets with OPT RRs (with or without options), thus several DNS packets with OPT RRs (with or without options), thus several
probes are required to discover what is supported. probes are required to discover what is supported.
Probing, if implemented, MUST be repeated periodically, e.g., daily. Probing, if implemented, MUST be repeated periodically, e.g., daily.
If an Authoritative Nameserver indicates ECS support for one zone, it If an Authoritative Nameserver indicates ECS support for one zone, it
is to be expected that the Nameserver supports ECS for all of its is to be expected that the Nameserver supports ECS for all of its
zones. Likewise, an Authoritative Nameserver that uses ECS zones. Likewise, an Authoritative Nameserver that uses ECS
information for one of its zones, MUST indicate support for the information for one of its zones, MUST indicate support for the
option in all of its responses to ECS queries. If the option is option in all of its responses to ECS queries. If the option is
supported but not actually used for generating a response, its SCOPE supported but not actually used for generating a response, its SCOPE
PREFIX-LENGTH SHOULD be set to 0. PREFIX-LENGTH MUST 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 ECS, and that it will generally be enabled Resolvers will need to use ECS, and that it will generally be enabled
only if it offers a clear benefit to the users. only if it offers a clear benefit to the users.
To avoid the complexity of implementing a probing and detection To avoid the complexity of implementing a probing and detection
mechanism (and the possible query loss/delay that may come with it), mechanism (and the possible query loss/delay that may come with it),
an implementation could use a whitelist of Authoritative Namesevers an implementation could use a whitelist of Authoritative Namesevers
skipping to change at page 22, line 4 skipping to change at page 22, line 27
Akamai Technologies Akamai Technologies
8 Cambridge Ctr 8 Cambridge Ctr
Cambridge MA 02142-1413 Cambridge MA 02142-1413
USA 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, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro, Kumari, and Richard Rabbat from Google; Terry Farmer, Mark Teodoro,
Edward Lewis, and Eric Burger from Neustar; David Ulevitch and Edward Lewis, and Eric Burger from Neustar; David Ulevitch and
Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from Matthew Dempsky from OpenDNS; Patrick W. Gilmore and Steve Hill from
Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya
Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn; Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn;
John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer
from NLnet Labs; Antonio Querubin; and all of the other people that from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin;
replied to our emails on various mailing lists. 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 23, line 26 skipping to change at page 23, line 51
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.]
-02 to -03 (IETF)
o Clean up the open issues, mostly by saying that they were out of
scope for this document.
o How in the world did no reviewers note that "Queries" had been
spelled as "Querys" in the title? (Aaron Falk did.)
-01 to -02 (IETF)
o Note ambiguity with multiple RRsets appearing in reply, eg, for an
ANY query or CNAME chain. (Duane Wessels)
o Open issue questioning the guidance about resolvers behind a NAT.
How do they know they are? What real requirement is this
imposing? (Duane Wessels)
o Some other wording changes based on Duane's review of an earlier
draft.
-00 to -01 (IETF) -00 to -01 (IETF)
o <David> Made the document describe how things are actually o <David> Made the document describe how things are actually
implmented now. This makes the document be more of a "this is how implmented now. This makes the document be more of a "this is how
we are doing things, this provides information on that". There we are doing things, this provides information on that". There
may be a future document that describes additional funcationality. may be a future document that describes additional funcationality.
o NETMASK was not a good desription, changed to PREFIX-LENGTH o NETMASK was not a good desription, changed to PREFIX-LENGTH
(Jinmei, others). Stole most of the definition for prefix length (Jinmei, others). Stole most of the definition for prefix length
from RFC4291. from RFC4291.
 End of changes. 34 change blocks. 
60 lines changed or deleted 96 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/