draft-ietf-dnsop-edns-client-subnet-07.txt   draft-ietf-dnsop-edns-client-subnet-08.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: September 22, 2016 D. Lawrence Expires: October 21, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
March 21, 2016 April 19, 2016
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-07 draft-ietf-dnsop-edns-client-subnet-08
Abstract Abstract
This document describes an EDNS0 extension that is in active use to This document describes an EDNS0 extension that is in active use to
carry information about the network that originated a DNS query, and carry information about the network that originated a DNS query, and
the network for which the subsequent response can be cached. Since the network for which the subsequent response can be cached. Since
it has some known operational and privacy shortcomings, a revision it has some known operational and privacy shortcomings, a revision
will be worked through the IETF for improvement. will be worked through the IETF for improvement.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 22, 2016. This Internet-Draft will expire on October 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Privacy Note . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Description . . . . . . . . . . . . . . . . . . . . 8
7.1. Originating the Option . . . . . . . . . . . . . . . . . 8 7.1. Originating the Option . . . . . . . . . . . . . . . . . 8
7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8 7.1.1. Recursive Resolvers . . . . . . . . . . . . . . . . . 8
7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9 7.1.2. Stub Resolvers . . . . . . . . . . . . . . . . . . . 9
7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 9 7.1.3. Forwarding Resolvers . . . . . . . . . . . . . . . . 10
7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10 7.2. Generating a Response . . . . . . . . . . . . . . . . . . 10
7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10 7.2.1. Authoritative Nameserver . . . . . . . . . . . . . . 10
7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12 7.2.2. Intermediate Nameserver . . . . . . . . . . . . . . . 12
7.3. Handling ECS Responses and Caching . . . . . . . . . . . 13 7.3. Handling ECS Responses and Caching . . . . . . . . . . . 13
7.3.1. Caching the Response . . . . . . . . . . . . . . . . 13 7.3.1. Caching the Response . . . . . . . . . . . . . . . . 14
7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 14 7.3.2. Answering from Cache . . . . . . . . . . . . . . . . 15
7.4. Delegations and Negative Answers . . . . . . . . . . . . 15 7.4. Delegations and Negative Answers . . . . . . . . . . . . 15
7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 16 7.5. Transitivity . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 17 9. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 17
10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 19 11.2. Birthday Attacks . . . . . . . . . . . . . . . . . . . . 19
11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 20 11.3. Cache Pollution . . . . . . . . . . . . . . . . . . . . 20
12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 21 12. Sending the Option . . . . . . . . . . . . . . . . . . . . . 21
12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 22
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 24 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
16.1. Normative References . . . . . . . . . . . . . . . . . . 25 16.1. Normative References . . . . . . . . . . . . . . . . . . 25
16.2. Informative References . . . . . . . . . . . . . . . . . 26 16.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Document History . . . . . . . . . . . . . . . . . . 27 Appendix A. Document History . . . . . . . . . . . . . . . . . . 27
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 6, line 5 skipping to change at page 6, line 5
lowest latency, least number of hops, topological distance, ...). lowest latency, least number of hops, topological distance, ...).
Topologically Close: Refers to two hosts being close in terms of Topologically Close: Refers to two hosts being close in terms of
number of hops or time it takes for a packet to travel from one number of hops or time it takes for a packet to travel from one
host to the other. The concept of topological distance is only host to the other. The concept of topological distance is only
loosely related to the concept of geographical distance: two loosely related to the concept of geographical distance: two
geographically close hosts can still be very distant from a geographically close hosts can still be very distant from a
topological perspective, and two geographically distant hosts can topological perspective, and two geographically distant hosts can
be quite close on the network. be quite close on the network.
For a more comprehensive treatment of these DNS terms, please see For a more comprehensive treatment of DNS terms, please see
[RFC7719]. [RFC7719].
5. Overview 5. Overview
The general idea of this document is to provide an EDNS0 option to The general idea of this document is to provide an EDNS0 option to
allow Recursive Resolvers, if they are willing, to forward details allow Recursive Resolvers, if they are willing, to forward details
about the origin network from which a query is coming when talking to about the origin network from which a query is coming when talking to
other Nameservers. other Nameservers.
The format of the edns-client-subnet (ECS) EDNS0 option is described The format of the edns-client-subnet (ECS) EDNS0 option is described
skipping to change at page 9, line 43 skipping to change at page 9, line 43
almost certainly use to generate any Tailored Response in lieu of an almost certainly use to generate any Tailored Response in lieu of an
option. This allows the answer to be handled by the same caching option. This allows the answer to be handled by the same caching
mechanism as other queries, with an explicit indicator of the mechanism as other queries, with an explicit indicator of the
applicable scope. Subsequent Stub Resolver queries for /0 can then applicable scope. Subsequent Stub Resolver queries for /0 can then
be answered from this cached response. be answered from this cached response.
A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include
FAMILY and ADDRESS data, but should be prepared to handle a REFUSED FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
response if the Intermediate Nameserver that it queries has a policy response if the Intermediate Nameserver that it queries has a policy
that denies forwarding of the ADDRESS. If there is no ADDRESS set, that denies forwarding of the ADDRESS. If there is no ADDRESS set,
i.e. SOURCE PREFIX-LENGTH is set to 0, then FAMILY MUST be set to 0. i.e. SOURCE PREFIX-LENGTH is set to 0, then FAMILY SHOULD be set to
the transport over which the query is sent. This is for
interoperability; at least one major authoritative server will ignore
the option if FAMILY is not 1 or 2, even though it is irrelevant if
there are no ADDRESS bits.
7.1.3. Forwarding Resolvers 7.1.3. Forwarding Resolvers
Forwarding Resolvers essentially appear to be Stub Resolvers to Forwarding Resolvers essentially appear to be Stub Resolvers to
whatever Recursive Resolver is ultimately handling the query, but whatever Recursive Resolver is ultimately handling the query, but
look like a Recursive Resolver to their client. A Forwarding look like a Recursive Resolver to their client. A Forwarding
Resolver using this option MUST prepare it as described above in Resolver using this option MUST prepare it as described above in
Section 7.1.1, Recursive Resolvers. In particular, a Forwarding Section 7.1.1, Recursive Resolvers. In particular, a Forwarding
Resolver that implements this protocol MUST honor SOURCE PREFIX- Resolver that implements this protocol MUST honor SOURCE PREFIX-
LENGTH restrictions indicated in the incoming query from its client. LENGTH restrictions indicated in the incoming query from its client.
See also Section 7.5. See also Section 7.5.
Since the Recursive Resolver it contacts will treat the Forwarding Since the Recursive Resolver it contacts will treat the Forwarding
Resolver like a Stub Resolver, the Recursive Resolver's policies Resolver like a Stub Resolver, the Recursive Resolver's policies
regarding incoming ADDRESS information will apply in the same way. regarding incoming ADDRESS information will apply in the same way.
If the Forwarding Resolver receives a REFUSED response when it sends If the Forwarding Resolver receives a REFUSED response when it sends
a query which includes a non-zero ADDRESS, it MUST retry with FAMILY a query which includes a non-zero ADDRESS, it MUST retry with no
set to 0 and no ADDRESS. ADDRESS.
7.2. Generating a Response 7.2. Generating a Response
7.2.1. Authoritative Nameserver 7.2.1. Authoritative Nameserver
When a query containing an ECS option is received, an Authoritative When a query containing an ECS option is received, an Authoritative
Nameserver supporting ECS MAY use the address information specified Nameserver supporting ECS MAY use the address information specified
in the option in order to generate a tailored response. in the option in order to generate a tailored response.
Authoritative Nameservers that have not implemented or enabled Authoritative Nameservers that have not implemented or enabled
skipping to change at page 10, line 48 skipping to change at page 11, line 8
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, unless the query specified only the SOURCE match those in the query. Echoing back these values helps to
PREFIX-LENGTH for privacy (and thus with FAMILY set to 0 and no mitigate certain attack vectors, as described in Section 11.
ADDRESS). Echoing back these values helps to mitigate certain attack
vectors, as described in Section 11.
The SCOPE PREFIX-LENGTH in the response indicates the network for The SCOPE PREFIX-LENGTH in the response indicates the network for
which the answer is intended. which the answer is intended.
A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
indicates that the provided prefix length was not specific enough to indicates that the provided prefix length was not specific enough to
select the most appropriate Tailored Response. Future queries for select the most appropriate Tailored Response. Future queries for
the name within the specified network SHOULD use the longer SCOPE the name within the specified network SHOULD use the longer SCOPE
PREFIX-LENGTH. Factors affecting whether the Recursive Resolver PREFIX-LENGTH. Factors affecting whether the Recursive Resolver
would use the longer length include the amount of privacy masking the would use the longer length include the amount of privacy masking the
skipping to change at page 13, line 44 skipping to change at page 14, line 7
If a REFUSED response is received from an Authoritative Nameserver, If a REFUSED response is received from an Authoritative Nameserver,
an ECS-aware resolver MUST retry the query without ECS to distinguish an ECS-aware resolver MUST retry the query without ECS to distinguish
the response from one where the Authoritative Nameserver is not the response from one where the Authoritative Nameserver is not
responsible for the name, which is a common convention for the responsible for the name, which is a common convention for the
REFUSED status. Similarly, a client of a Recursive Resolver SHOULD REFUSED status. Similarly, a client of a Recursive Resolver SHOULD
retry for REFUSED because it is not sufficiently clear whether the retry for REFUSED because it is not sufficiently clear whether the
REFUSED was because of the ECS option or some other reason. REFUSED was because of the ECS option or some other reason.
7.3.1. Caching the Response 7.3.1. Caching the Response
In the cache, all resource records in the answer section MUST be to In the cache, all resource records in the answer section MUST be tied
the network specified in the response. The appropriate prefix length to the network specified in the response. The appropriate prefix
depends on the relationship between SOURCE PREFIX-LENGTH, SCOPE length depends on the relationship between SOURCE PREFIX-LENGTH,
PREFIX-LENGTH, and the maximum cacheable prefix length configured for SCOPE PREFIX-LENGTH, and the maximum cacheable prefix length
the cache. configured for the cache.
If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH store If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH store
SCOPE PREFIX-LENGTH bits of ADDRESS and mark the response as valid SCOPE PREFIX-LENGTH bits of ADDRESS and mark the response as valid
for all addresses that fall within that range. for all addresses that fall within that range.
Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the
cache, store SOURCE PREFIX-LENGTH bits of ADDRESS and mark the cache, store SOURCE PREFIX-LENGTH bits of ADDRESS and mark the
response as valid for all addresses that fall within that range. response as valid for all addresses that fall within that range.
If SOURCE PREFIX-LENGTH is shorter than the configured maximum and If SOURCE PREFIX-LENGTH is shorter than the configured maximum and
SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE
PREFIX-LENGTH bits of ADDRESS and mark the response as only valid to PREFIX-LENGTH bits of ADDRESS and mark the response as only valid to
answer client queries that specify exactly the same SOURCE PREFIX- answer client queries that specify exactly the same SOURCE PREFIX-
LENGTH in their own ECS option. LENGTH in their own ECS option.
DNSKEY and DS records are the one exception to the above rules for The handling of DNSSEC-related records in the answer section was
records in the answer section. These records SHOULD always be cached unspecified in the original draft and inconsistently handled in
at /0. See Section 9 for more. existing implementations. An RRSIG must obviously be tied to the
RRset which it signs, but it is RECOMMENDED that all other DNSSEC
records be scoped at /0. See Section 9 for more.
Note that the additional and authority sections from a DNS response Note that the additional and authority sections from a DNS response
message are specifically excluded here. Any records from these message are specifically excluded here. Any records from these
sections MUST NOT be tied to a network. See more at Section 7.4. sections MUST NOT be tied to a network. See more at Section 7.4.
Records that are cached as /0 because of a query's SOURCE PREFIX- Records that are cached as /0 because of a query's SOURCE PREFIX-
LENGTH of 0 MUST be distinguished from those that are cached as /0 LENGTH of 0 MUST be distinguished from those that are cached as /0
because of a response's SCOPE PREFIX-LENGTH of 0. The former should because of a response's SCOPE PREFIX-LENGTH of 0. The former should
only be used for other /0 queries that the Intermediate Resolver only be used for other /0 queries that the Intermediate Resolver
receives, but the latter is suitable as a response for all networks. receives, but the latter is suitable as a response for all networks.
skipping to change at page 15, line 9 skipping to change at page 15, line 18
7.3.2. Answering from Cache 7.3.2. Answering from Cache
Cache lookups are first done as usual for a DNS query, using the Cache lookups are first done as usual for a DNS query, using the
query tuple of <name, type, class>. Then the appropriate RRset MUST query tuple of <name, type, class>. Then the appropriate RRset MUST
be chosen based on longest prefix matching. The client address to be chosen based on longest prefix matching. The client address to
use for comparison will depend on whether the Intermediate Nameserver use for comparison will depend on whether the Intermediate Nameserver
received an ECS option in its client query. received an ECS option in its client query.
o If no ECS option was provided, the client's address is used. o If no ECS option was provided, the client's address is used.
o If there was an ECS option specifying SOURCE PREFIX-LENGTH but no o If there was an ECS option specifying SOURCE PREFIX-LENGTH and
ADDRESS, the client's address is used but SOURCE PREFIX-LENGTH is ADDRESS covering the client's address, the client address is used
initially ignored. If no covering entry is found and SOURCE but SOURCE PREFIX-LENGTH is initially ignored. If no covering
PREFIX-LENGTH is shorter than the configured maximum length entry is found and SOURCE PREFIX-LENGTH is shorter than the
allowed for the cache, repeat the cache lookup for an entry that configured maximum length allowed for the cache, repeat the cache
exactly matches SOURCE PREFIX-LENGTH. These special entries, lookup for an entry that exactly matches SOURCE PREFIX-LENGTH.
which do not cover longer prefix lengths, occur as described in These special entries, which do not cover longer prefix lengths,
the previous section. occur as described in the previous section.
o If there was an ECS option with an ADDRESS, the ADDRESS from it o If there was an ECS option with an ADDRESS, the ADDRESS from it
MAY be used if local policy allows. Policy can vary depending on MAY be used if local policy allows. Policy can vary depending on
the agreements the operator of the Intermediate Nameserver has the agreements the operator of the Intermediate Nameserver has
with Authoritative Nameserver operators; see Section 12.2. If with Authoritative Nameserver operators; see Section 12.2. If
policy does not allow, a REFUSED response SHOULD be sent. See policy does not allow, a REFUSED response SHOULD be sent. See
Section 7.5 for more. Section 7.5 for more.
If a matching network is found and the relevant data is unexpired, If a matching network is found and the relevant data is unexpired,
the response is generated as per Section 7.2. the response is generated as per Section 7.2.
skipping to change at page 16, line 7 skipping to change at page 16, line 16
For negative answers, some independent implementations of both For negative answers, some independent implementations of both
resolvers and authorities did not see the section restriction as resolvers and authorities did not see the section restriction as
necessarily meaning that a given name and type must only have either necessarily meaning that a given name and type must only have either
positive ECS-tagged answers or a negative answer. They support being positive ECS-tagged answers or a negative answer. They support being
able to tell one part of the network that the data does not exist, able to tell one part of the network that the data does not exist,
while telling another part of the network that it does. while telling another part of the network that it does.
Several other implementations, however, do not support being able to Several other implementations, however, do not support being able to
mix positive and negative answers, and thus interoperability is a mix positive and negative answers, and thus interoperability is a
problem. It is recommended that no specific behavior regarding problem. It is RECOMMENDED that no specific behavior regarding
negative answers be relied upon. negative answers be relied upon, but that Authoritative Nameservers
should conservatively expect that Intermediate Nameservers will treat
all negative answers as /0 and therefore SHOULD set SCOPE PREFIX-
LENGTH accordingly.
This issue is expected to be revisited in a future revision of the This issue is expected to be revisited in a future revision of the
protocol, possibly blessing the mixing of positive and negative protocol, possibly blessing the mixing of positive and negative
answers. There are implications for cache data structures that answers. There are implications for cache data structures that
developers should consider when writing new ECS code. developers should consider when writing new ECS code.
The delegations case is a bit easier to tease out. In operational The delegations case is a bit easier to tease out. In operational
practice, if an authoritative server is using address information to practice, if an authoritative server is using address information to
provide customized delegations, it is the resolver that will be using provide customized delegations, it is the resolver that will be using
the answer for its next iterative query. Addresses in the Additional the answer for its next iterative query. Addresses in the Additional
skipping to change at page 16, line 40 skipping to change at page 17, line 4
Intermediate Nameservers. Intermediate Nameservers.
Any Intermediate Nameserver that forwards ECS options received from Any Intermediate Nameserver that forwards ECS options received from
its clients MUST fully implement the caching behavior described in its clients MUST fully implement the caching behavior described in
Section 7.3. Section 7.3.
An Intermediate Nameserver MAY forward ECS options with address An Intermediate Nameserver MAY forward ECS options with address
information. This information MAY match the source IP address of the information. This information MAY match the source IP address of the
incoming query, and MAY have more or fewer address bits than the incoming query, and MAY have more or fewer address bits than the
Nameserver would normally include in a locally originated ECS option. Nameserver would normally include in a locally originated ECS option.
If an Intermediate Nameserver receives a query with SOURCE PREFIX- If an Intermediate Nameserver receives a query with SOURCE PREFIX-
LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace LENGTH set to 0 it MUST NOT include client address information in
it with more accurate address information. queries made to resolve that client's request (see Section 7.1.2).
If for any reason the Intermediate Nameserver does not want to use If for any reason the Intermediate Nameserver does not want to use
the information in an ECS option it receives (too little address the information in an ECS option it receives (too little address
information, network address from a range not authorized to use the information, network address from a range not authorized to use the
server, private/unroutable address space, etc), it SHOULD drop the server, private/unroutable address space, etc), it SHOULD drop the
query and return a REFUSED response. Note again that a query MUST query and return a REFUSED response. Note again that a query MUST
NOT be refused solely because it provides 0 address bits. NOT be refused solely because it provides 0 address bits.
Be aware that at least one major existing implementation does not Be aware that at least one major existing implementation does not
return REFUSED and instead just processes the query as though the return REFUSED and instead just processes the query as though the
skipping to change at page 17, line 31 skipping to change at page 17, line 45
The presence or absence of an [RFC6891] EDNS0 OPT resource record The presence or absence of an [RFC6891] EDNS0 OPT resource record
containing an ECS option in a DNS query does not change the usage of containing an ECS option in a DNS query does not change the usage of
the resource records and mechanisms used to provide data origin the resource records and mechanisms used to provide data origin
authentication and data integrity to the DNS, as described in authentication and data integrity to the DNS, as described in
[RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed.
Use of this option, however, does imply increased DNS traffic between Use of this option, however, does imply increased DNS traffic between
any given Recursive Resolver and Authoritative Nameserver, which any given Recursive Resolver and Authoritative Nameserver, which
could be another barrier to further DNSSEC adoption in this area. could be another barrier to further DNSSEC adoption in this area.
It is expected that in a signed zone using ECS all signatures will The initial draft of this protocol, against which several
use the same DNSKEY record independent of the Tailored Response that authoritative and recursive nameserver implementations were written,
should be cached per network. Trying to establish a network-specific did not discuss the handling of DNSSEC RRs and thus it is expected
chain of trust from a non-ECS-enabled zone into an ECS-enabled zone, that there are operational inconsistencies in handling them.
which tecnically feasbile, has no apparent benefits. Therefore,
while RRSIGs are obviously tied to the same network as the Tailored
Response that they cover, DNSKEY and DS records SHOULD be invariant
for all clients.
NSEC and NSEC3 are explicitly not addressed in this specification per Given the intention of this document to describe how ECS is currently
the discussion about negative answers in Section 7.4. deployed, specifying new requirements for DNSSEC handling is out of
scope. However, some recommendations can be made as to what is most
likely to result in successful interopration for a DNSSEC-signed ECS
zone, mainly from the point of view of Authoritative Nameservers.
Most DNSSEC records SHOULD be scoped at /0, except for the RRSIG
records which MUST be tied to the RRset that they sign in a Tailored
Response. While it is possible to conceive of a way to get other
DNSSEC records working in a network-specific way, it has little
apparent benefit or likelihood of working with deployed validating
resolvers.
One further implication here is that, despite the discussion about
negative answers in Section 7.4, scoping NSEC or NSEC3 records at /0
per the previous paragraph necessarily implies that DNSSEC-signed
negative answers must also be network-invariant.
10. NAT Considerations 10. NAT Considerations
Special awareness of ECS in devices that perform Network Address Special awareness of ECS in devices that perform Network Address
Translation (NAT) as described in [RFC2663] is not required; queries Translation (NAT) as described in [RFC2663] is not required; queries
can be passed through as-is. The client's network address SHOULD NOT can be passed through as-is. The client's network address SHOULD NOT
be added, and existing ECS options, if present, SHOULD NOT be be added, and existing ECS options, if present, SHOULD NOT be
modified by NAT devices. modified by NAT devices.
In large-scale global networks behind a NAT device (but for example In large-scale global networks behind a NAT device (but for example
skipping to change at page 22, line 38 skipping to change at page 23, line 10
the feature to only certain clients. For example, a CDN that does the feature to only certain clients. For example, a CDN that does
not want all of their mapping trivially walked might require a legal not want all of their mapping trivially walked might require a legal
agreement with the Recursive Resolver operator, to clearly describe agreement with the Recursive Resolver operator, to clearly describe
the acceptable use of the feature. the acceptable use of the feature.
The maintenance of access control mechanisms is out of scope for this The maintenance of access control mechanisms is out of scope for this
protocol definition. protocol definition.
13. Example 13. Example
1. A stub resolver, SR, with IP address 192.0.2.37, tries to 1. A stub resolver, SR, with IP address
resolve www.example.com by forwarding the query to the Recursive 2001:0db8:fd13:4231:2112:8a2e:c37b:7334 tries to resolve
www.example.com by forwarding the query to the Recursive
Resolver, RNS, asking for recursion. Resolver, RNS, asking for recursion.
2. RNS, supporting ECS, looks up www.example.com in its cache. An 2. RNS, supporting ECS, looks up www.example.com in its cache. An
entry is found neither for www.example.com, nor for example.com. entry is found neither for www.example.com, nor for example.com.
3. RNS builds a query to send to the root and .com servers. The 3. RNS builds a query to send to the root and .com servers. The
implementation of RNS provides facilities so an administrator implementation of RNS provides facilities so an administrator
can configure it not to forward ECS in certain cases. In can configure it not to forward ECS in certain cases. In
particular, RNS is configured to not include an ECS option when particular, RNS is configured to not include an ECS option when
talking to TLD or root nameservers, as described in Section 7.1. talking to TLD or root nameservers, as described in Section 7.1.
Thus, no ECS option is added, and resolution is performed as Thus, no ECS option is added, and resolution is performed as
usual. usual.
4. RNS now knows the next server to query: the Authoritative 4. RNS now knows the next server to query: the Authoritative
Nameserver, ANS, responsible for example.com. Nameserver, ANS, responsible for example.com.
5. RNS prepares a new query for www.example.com, including an ECS 5. RNS prepares a new query for www.example.com, including an ECS
option with: option with:
* OPTION-CODE, set to 8. * OPTION-CODE set to 8.
* OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4 * OPTION-LENGTH set to 0x00 0x0b for the following fixed 4
octets plus the 3 octets that will be used for ADDRESS. octets plus the 7 octets that will be used for ADDRESS.
* FAMILY, set to 0x00 0x01 as IP is an IPv4 address. * FAMILY set to 0x00 0x02 as IP is an IPv6 address.
* SOURCE PREFIX-LENGTH, set to 0x18, as RNS is configured to * SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to
conceal the last 8 bits of every IPv4 address. conceal the last 72 bits of every IPv6 address.
* SCOPE PREFIX-LENGTH, set to 0x00, as specified by this * SCOPE PREFIX-LENGTH set to 0x00, as specified by this
document for all queries. document for all queries.
* ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24 * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing
bits of the IPv4 address. only the first 56 bits of the IPv6 address.
6. The query is sent. ANS understands and uses ECS. It parses the 6. The query is sent. ANS understands and uses ECS. It parses the
ECS option, and generates a Tailored Response. ECS option, and generates a Tailored Response.
7. Due its internal implementation, ANS finds a response that is 7. Due its internal implementation, ANS finds a response that is
tailored for the whole /16 of the client that performed the tailored for the whole /16 of the client that performed the
query. query.
8. ANS adds an ECS option in the response, containing: 8. ANS adds an ECS option in the response, containing:
* OPTION-CODE, set to 8. * OPTION-CODE set to 8.
* OPTION-LENGTH, set to 0x00 0x07. * OPTION-LENGTH set to 0x00 0x07.
* FAMILY, set to 0x00 0x01. * FAMILY set to 0x00 0x02.
* SOURCE PREFIX-LENGTH, set to 0x18, copied from the query. * SOURCE PREFIX-LENGTH set to 0x38, copied from the query.
* SCOPE PREFIX-LENGTH, set to 0x10, indicating a /16 network. * SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.
* ADDRESS, set to 0xC0 0x00 0x02, copied from the query. * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied
from the query.
9. RNS receives the response containing an ECS option. It verifies 9. RNS receives the response containing an ECS option. It verifies
that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query. that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query.
If not, the message is discarded. If not, the message is discarded.
10. The response is interpreted as usual. Since the response 10. The response is interpreted as usual. Since the response
contains an ECS option, the ADDRESS, SCOPE PREFIX-LENGTH, 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
skipping to change at page 27, line 22 skipping to change at page 27, line 51
<http://www.rfc-editor.org/info/rfc2663>. <http://www.rfc-editor.org/info/rfc2663>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
Appendix A. Document History Appendix A. Document History
[RFC Editor: Please delete this section before publication.] [RFC Editor: Please delete this section before publication.]
-07 to -08:
o Jinmei observed that one section saying a /0 "MUST forward the
query as-is" was in conflict with the section that said the option
could be modified to contain the Recursive Resolver address.
o Clarify that existing implementations don't interoperate w.r.t
DNSSEC.
o Removed vestiges of able to set FAMILY to 0 when specifying just a
SOURCE PREFIX-LENGTH and no ADDRESS. Doesn't interoperate.
o Minor wording change in reference to DNS terminology draft.
o Change example to use IPv6 per Fred Baker's request.
-06 to -07: -06 to -07:
o Minor comments from Suzanne, Mukund, Jinmei and from the IESG on o Minor comments from Suzanne, Mukund, Jinmei and from the IESG on
the dnsop list. the dnsop list.
o Incorporated feedback from conference call with Mukund and Evan, o Incorporated feedback from conference call with Mukund and Evan,
notably clarifying what prefix length to associate with answers in notably clarifying what prefix length to associate with answers in
the cache, how and why to deaggregate, and some DNSSEC stuff. the cache, how and why to deaggregate, and some DNSSEC stuff.
-05 to -06: -05 to -06:
 End of changes. 37 change blocks. 
72 lines changed or deleted 109 lines changed or added

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