< draft-ietf-dnsop-edns-client-subnet-02.txt   draft-ietf-dnsop-edns-client-subnet-03.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: January 7, 2016 D. Lawrence Expires: February 25, 2016 D. Lawrence
Akamai Technologies Akamai Technologies
W. Kumari W. Kumari
Google Google
July 6, 2015 August 24, 2015
Client Subnet in DNS Queries Client Subnet in DNS Queries
draft-ietf-dnsop-edns-client-subnet-02 draft-ietf-dnsop-edns-client-subnet-03
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 January 7, 2016. This Internet-Draft will expire on February 25, 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 3, line 6 skipping to change at page 3, line 6
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 . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Probing . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Whitelist . . . . . . . . . . . . . . . . . . . . . . . 19
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 24
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Document History . . . . . . . . . . . . . . . . . . 23 Appendix A. Document History . . . . . . . . . . . . . . . . . . 24
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 12, line 8 skipping to change at page 12, line 8
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 non-zero fields in the ADDRESS in the response don't match the non-zero fields in the
corresponding query, the full response MUST be dropped, as described corresponding query, the full response MUST be dropped, as described
in Section 10. For a response to query which specified only the in Section 10. For a response to a query which specified only the
SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS SOURCE PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS
fields should contain the appropriate non-zero information for fields should contain the appropriate non-zero information for
caching. caching.
If no ECS option is contained in the response, the Intermediate If no ECS option is contained in the response, the Intermediate
Nameserver SHOULD treat this as being equivalent to having received a Nameserver SHOULD treat this as being equivalent to having received a
SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
addresses. See further discussion on the security implications of addresses. See further discussion on the security implications of
this in Section 10. this in Section 10.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
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
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. other criteria, such as zone or query type. As of the time of this
writing, at least one implemetaion makes use of a whitelist.
An additional advantage of using a whitelist is that partial client An advantage of using a whitelist is that partial client address
address information is only disclosed to Nameservers that are known information is only disclosed to Nameservers that are known to use
to use the information, improving privacy. the information, improving privacy.
A major drawback is scalability. The operator needs to track which A drawback is scalability. 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 22, line 44 skipping to change at page 22, line 44
John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer John Dickinson from Sinodun; Mark Delany from Apple; Yuri Schaeffer
from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin; from NLnet Labs; Duane Wessels from from Verisign; Antonio Querubin;
and all of the other people that replied to our emails on various and all of the other people that replied to our emails on various
mailing lists. 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, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[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, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. DOI 10.17487/RFC1700, October 1994,
<http://www.rfc-editor.org/info/rfc1700>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", BCP and E. Lear, "Address Allocation for Private Internets",
5, RFC 1918, February 1996. BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011. Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/
RFC6177, March 2011,
<http://www.rfc-editor.org/info/rfc6177>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013. 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
15.2. Informative References 15.2. Informative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>.
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) -02 to -03:
o Some cleanup of the whitelist text.
-01 to -02 (IETF)
o Clean up the open issues, mostly by saying that they were out of o Clean up the open issues, mostly by saying that they were out of
scope for this document. scope for this document.
o How in the world did no reviewers note that "Queries" had been o How in the world did no reviewers note that "Queries" had been
spelled as "Querys" in the title? (Aaron Falk did.) spelled as "Querys" in the title? (Aaron Falk did.)
-01 to -02 (IETF) -00 to -01 (IETF)
o Note ambiguity with multiple RRsets appearing in reply, eg, for an o Note ambiguity with multiple RRsets appearing in reply, eg, for an
ANY query or CNAME chain. (Duane Wessels) ANY query or CNAME chain. (Duane Wessels)
o Open issue questioning the guidance about resolvers behind a NAT. o Open issue questioning the guidance about resolvers behind a NAT.
How do they know they are? What real requirement is this How do they know they are? What real requirement is this
imposing? (Duane Wessels) imposing? (Duane Wessels)
o Some other wording changes based on Duane's review of an earlier o Some other wording changes based on Duane's review of an earlier
draft. draft.
-00 to -01 (IETF) -IND to -00 (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. 27 change blocks. 
34 lines changed or deleted 56 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/