< draft-ietf-dnsop-edns-client-subnet-05.txt   draft-ietf-dnsop-edns-client-subnet-06.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: June 16, 2016 D. Lawrence Expires: June 17, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
December 14, 2015 December 15, 2015
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-05 draft-ietf-dnsop-edns-client-subnet-06
Abstract Abstract
This document defines an EDNS0 extension to carry information about This document 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. the subsequent response can be cached.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 June 16, 2016. This Internet-Draft will expire on June 17, 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 8, line 45 skipping to change at page 8, line 45
with trailing 0 bits added, if needed, to fill the final octet. The with trailing 0 bits added, if needed, to fill the final octet. The
total number of octets used MUST only be enough to cover SOURCE total number of octets used MUST only be enough to cover SOURCE
PREFIX-LENGTH bits, rather than the full width that would normally be PREFIX-LENGTH bits, rather than the full width that would normally be
used by addresses in FAMILY. used by addresses in FAMILY.
FAMILY and ADDRESS information MAY be used from the ECS option in the FAMILY and ADDRESS information MAY be used from the ECS option in the
incoming query. Passing the existing address data is supportive of incoming query. Passing the existing address data is supportive of
the Recursive Resolver being used as the target of a Forwarding the Recursive Resolver being used as the target of a Forwarding
Resolver, but could possibly run into policy problems with regard to Resolver, but could possibly run into policy problems with regard to
usage agreements between the Recursive Resolver and Authoritative usage agreements between the Recursive Resolver and Authoritative
Namserver. See Section 12.2 for more discussion on this point. If Nameserver. See Section 12.2 for more discussion on this point. If
the Recursive Resolver will not forward the FAMILY and ADDRESS data the Recursive Resolver will not forward the FAMILY and ADDRESS data
from the incoming ECS option, it SHOULD return a REFUSED response. from the incoming ECS option, it SHOULD return a REFUSED response.
Subsequent queries to refresh the data MUST, if unrestricted by an Subsequent queries to refresh the data MUST, if unrestricted by an
incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX- incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
LENGTH that the Recursive Resolver is willing to cache, even if a LENGTH that the Recursive Resolver is willing to cache, even if a
previous response indicated that a shorter prefix length was previous response indicated that a shorter prefix length was
sufficient. sufficient.
7.1.2. Stub Resolvers 7.1.2. Stub Resolvers
skipping to change at page 9, line 46 skipping to change at page 9, line 46
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 in the Resolver using this option MUST prepare it as described in the
Section 7.1.1 section above. In particular, a Forwarding Resolver Section 7.1.1 section above. In particular, a Forwarding Resolver
that implements this protocol MUST honor SOURCE PREFIX-LENGTH that implements this protocol MUST honor SOURCE PREFIX-LENGTH
restrictions indicated in the incoming query from its client. See restrictions indicated in the incoming query from its client. See
also Section 7.5. also Section 7.5.
Since the Recursive Resolver it contacts will treat it like a Stub Since the Recursive Resolver it contacts will treat it like a Stub
Resolver, the Recursive Resolver's policies regarding incoming Resolver, the Recursive Resolver's policies regarding incoming
ADDRESS information will apply in the same way. If the Forwarding ADDRESS information will apply in the same way. If the Forwarding
Resover receives a REFUSED response when it sends a query which Resolver receives a REFUSED response when it sends a query which
includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS includes a non-zero ADDRESS, it MUST retry with FAMILY and ADDRESS
set to 0. set to 0.
7.2. Generating a Response 7.2. Generating a Response
7.2.1. Authoritative Nameserver 7.2.1. Authoritative Nameserver
When a query containing an ECS option is received, an Authoritative When a query containing an ECS option is received, an Authoritative
Nameserver supporting ECS MAY use the address information specified Nameserver supporting ECS MAY use the address information specified
in the option in order to generate a tailored response. in the option in order to generate a tailored response.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
user manual. user manual.
7.2.2. Intermediate Nameserver 7.2.2. Intermediate Nameserver
When an Intermediate Nameserver uses ECS, whether it passes an ECS When an Intermediate Nameserver uses ECS, whether it passes an ECS
option in its own response to its client is predicated on whether the option in its own response to its client is predicated on whether the
client originally included the option. Because a client that did not client originally included the option. Because a client that did not
use an ECS option might not be able to understand it, the server MUST use an ECS option might not be able to understand it, the server MUST
NOT provide one in its response. If the client query did include the NOT provide one in its response. If the client query did include the
option, the server MUST include one in its response, especially as it option, the server MUST include one in its response, especially as it
could be talking to a Forwaring Resolver which would need the could be talking to a Forwarding Resolver which would need the
information for its own caching. information for its own caching.
If an Intermediate Nameserver receives a response which has a longer If an Intermediate Nameserver receives a response which has a longer
SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in SCOPE PREFIX-LENGTH than the SOURCE PREFIX-LENGTH that it provided in
its query, it SHOULD still provide the result as the answer to the its query, it SHOULD still provide the result as the answer to the
triggering client request even if the client is in a different triggering client request even if the client is in a different
address range. The Intermediate Nameserver MAY instead opt to retry address range. The Intermediate Nameserver MAY instead opt to retry
with a longer SOURCE PREFIX-LENGTH to get a better reply before with a longer SOURCE PREFIX-LENGTH to get a better reply before
responding to its client, as long as it does not exceed a SOURCE responding to its client, as long as it does not exceed a SOURCE
PREFIX-LENGTH specified in the query that triggered resolution, but PREFIX-LENGTH specified in the query that triggered resolution, but
skipping to change at page 13, line 7 skipping to change at page 13, line 7
caching. caching.
If no ECS option is contained in the response, the Intermediate If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of addresses. See further discussion on the security implications of
this in Section 11. this in Section 11.
If a REFUSED response is received from an Authoritative Nameserver, 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 authoritative response from a lame delegation, which is the the response from one where the Authoritative Nameserver is not
common convention for a REFUSED status. Similarly, a client of a responsible for the name, which is a common convention for the
Recursive Resolver should retry for REFUSED because it is not REFUSED status. Similarly, a client of a Recursive Resolver should
sufficiently clear whether the REFUSED was because of the ECS option retry for REFUSED because it is not sufficiently clear whether the
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 tied In the cache, all resource records in the answer section MUST be tied
to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX- to the network specified by the FAMILY, ADDRESS and SCOPE PREFIX-
LENGTH fields, as limited by the Intermediate Nameserver's own LENGTH fields, as limited by the Intermediate Nameserver's own
configuration for maximum cacheable prefix length. Note that the configuration for maximum cacheable prefix length. Note that the
additional and authority sections from a DNS response message are additional and authority sections from a DNS response message are
specifically excluded here. Any records from these sections MUST NOT specifically excluded here. Any records from these sections MUST NOT
be tied to a network. See more at Section 7.4. be tied to a network. See more at Section 7.4.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
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. problem. It is recommended that no specific behaviour regarding
negative answers be relied upon.
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.
7.5. Transitivity 7.5. Transitivity
Generally, ECS options will only be present in DNS messages between a Generally, ECS options will only be present in DNS messages between a
Recursive Resolver and an Authoritative Nameserver, i.e., one hop. Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
In certain configurations however, for example multi-tier nameserver In certain configurations however, for example multi-tier nameserver
setups, it may be necessary to implement transitive behaviour on setups, it may be necessary to implement transitive behaviour on
Intermediate Nameservers. Intermediate Nameservers.
Any Intermediate Nameserver that forwards ECS options received from Any Intermediate Nameserver that forwards ECS options received from
their clients MUST fully implement the caching behaviour described in their clients MUST fully implement the caching behaviour described in
Section 7.3. Section 7.3.
Intermediate Nameservers supporting ECS MUST forward options with An Intermediate Nameserver MAY forward ECS options with address
SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such information. This information MAY match the source IP address of the
options MUST NOT be replaced with more accurate address information. incoming query, and MAY have more or fewer address bits than the
Nameserver would normally include in a locally originated ECS option.
An Intermediate Nameserver MAY also forward ECS options with actual If an Intermediate Nameservers receives a query with SOURCE PREFIX-
address information. This information MAY match the source IP LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace
address of the incoming query, and MAY have more or fewer address it with more accurate address information.
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 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 process the query as though the return REFUSED and instead just process the query as though the
skipping to change at page 19, line 14 skipping to change at page 19, line 14
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 any 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 NOT 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.
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
ECS options that are either obviously forged or otherwise known to ECS options that are either obviously forged or otherwise known to
skipping to change at page 20, line 4 skipping to change at page 20, line 4
12.1. Probing 12.1. Probing
A Recursive Resolver can send the ECS option with every outgoing A Recursive Resolver can send the ECS option with every outgoing
query. However, it is RECOMMENDED that Resolvers remember which query. However, it is RECOMMENDED that Resolvers remember which
Authoritative Nameservers did not return the option with their Authoritative Nameservers did not return the option with their
response, and omit client address information from subsequent queries response, and omit client address information from subsequent queries
to those Nameservers. to those Nameservers.
Additionally, Recursive Resolvers SHOULD be configured to never send Additionally, Recursive Resolvers SHOULD be configured to never send
the option when querying root, top-level, and effective top-level the option when querying root, top-level, and effective top-level
(ie, ("public suffic") [Public_Suffix_List] domain servers. These (ie, ("public suffix") [Public_Suffix_List] domain servers. These
domains are delegation-centric and are very unlikely to generate domains are delegation-centric and are very unlikely to generate
different responses based on the address of the client. different responses based on the address of the client.
When probing, it is important that several things are probed: support When probing, it is important that several things are probed: support
for ECS, support for EDNS0, support for EDNS0 options, or possibly an for ECS, support for EDNS0, support for EDNS0 options, or possibly an
unreachable Nameserver. Various implementations are known to drop unreachable Nameserver. Various implementations are known to drop
DNS packets with OPT RRs (with or without options), thus several DNS packets with OPT RRs (with or without options), thus several
probes are required to discover what is supported. probes are required to discover what is supported.
Probing, if implemented, MUST be repeated periodically, e.g., daily. Probing, if implemented, MUST be repeated periodically, e.g., daily.
skipping to change at page 20, line 31 skipping to change at page 20, line 31
PREFIX-LENGTH MUST be set to 0. PREFIX-LENGTH MUST be set to 0.
12.2. Whitelist 12.2. Whitelist
As described previously, it is expected that only a few Recursive As described previously, it is expected that only a few Recursive
Resolvers will need to use ECS, and that it will generally be enabled Resolvers will need to use ECS, and that it will generally be enabled
only if it offers a clear benefit to the users. only if it offers a clear benefit to the users.
To avoid the complexity of implementing a probing and detection To avoid the complexity of implementing a probing and detection
mechanism (and the possible query loss/delay that may come with it), mechanism (and the possible query loss/delay that may come with it),
an implementation could use a whitelist of Authoritative Namesevers an implementation could use a whitelist of Authoritative Nameservers
to send the option to, likely specified by their domain name. to send the option to, likely specified by their domain name.
Implementations MAY also allow additionally configuring this based on Implementations MAY also allow additionally configuring this based on
other criteria, such as zone or query type. As of the time of this other criteria, such as zone or query type. As of the time of this
writing, at least one implemetaion makes use of a whitelist. writing, at least one implementation makes use of a whitelist.
An advantage of using a whitelist is that partial client address An advantage of using a whitelist is that partial client address
information is only disclosed to Nameservers that are known to use information is only disclosed to Nameservers that are known to use
the information, improving privacy. the information, improving privacy.
A drawback is scalability. The operator needs to track which A drawback is saleability. The operator needs to track which
Authoritative Nameservers support ECS, making it harder for new Authoritative Nameservers support ECS, making it 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 Similarly, Authoritative Nameservers can also use whitelists to limit
the feature to only certain clients. For example, a CDN that does the feature to only certain clients. For example, a CDN that does
not want all of their mapping trivially walked might require a legal not want all of their mapping trivially walked might require a legal
agreement with the Recursive Resolver operator, to clearly describe agreement with the Recursive Resolver operator, to clearly describe
the acceptable use of the feature. the acceptable use of the feature.
The maintenance of access control mechanisms is out of scope for this The maintenance of access control mechanisms is out of scope for this
skipping to change at page 23, line 29 skipping to change at page 23, line 29
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 Infoblox; Andrew Sullivan from Dyn; John Dickinson from Jinmei from Infoblox; Andrew Sullivan from Dyn; John Dickinson from
Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs; Sinodun; Mark Delany from Apple; Yuri Schaeffer from NLnet Labs;
Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn Duane Wessels from from Verisign; Antonio Querubin; Daniel Kahn
Gillmor from the ACLU, and all of the other people that replied to Gillmor from the ACLU, Russ Housley and all of the other people that
our emails on various mailing lists. replied to our emails on various mailing lists.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 25, line 35 skipping to change at page 25, line 35
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, DOI 10.17487/RFC2663, August 1999, 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>. <http://www.rfc-editor.org/info/rfc2663>.
Appendix A. Document History Appendix A. Document History
[RFC Editor: Please delete this section before publication.] [RFC Editor: Please delete this section before publication.]
-05 to -06(?): -05 to -06:
o Minor wording clarifications. (David Kahn Gillmor) o Integrated David Lawrence comments.
o Ran spellcheck again. One ady I';; laern to tyoe/
-04 to -05: -04 to -05:
o Moved comment about retrying for REFUSED to section on "Handling o Moved comment about retrying for REFUSED to section on "Handling
ECS Responses". (Jinmei) ECS Responses". (Jinmei)
o Clarify that a new proposal for an improved ECS protool is o Clarify that a new proposal for an improved ECS protool is
expected. expected.
o "Forwarders" had been used as though they were the source of a o "Forwarders" had been used as though they were the source of a
forwarded query rather than the targeted of one; clarified and forwarded query rather than the targeted of one; clarified and
defined as "Forwarding Resolver". (Jinmei) defined as "Forwarding Resolver". (Jinmei)
o "representing the leftmost significant bits" => "representing the o "representing the leftmost significant bits" => "representing the
leftmost number of significant bits". (Jinmei) leftmost number of significant bits". (Jinmei)
o Minor other clarifying text. (Jinmei) o Minor other clarifying text. (Jinmei)
o Jinmei's affiliation. o Jinmei's affiliation.
o Minor wording clarifications. (David Kahn Gillmor)
o Russ Housely's GenART review.
-03 to -04: -03 to -04:
o Privacy note per Ted Hardie's suggestion. o Privacy note per Ted Hardie's suggestion.
o MUST use minimum octet length to cover PREFIX bits. o MUST use minimum octet length to cover PREFIX bits.
o Expose note about documenting deployed, if flawed, protocol. o Expose note about documenting deployed, if flawed, protocol.
-02 to -03: -02 to -03:
 End of changes. 19 change blocks. 
31 lines changed or deleted 36 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/