draft-ietf-dnsop-qname-minimisation-03.txt   draft-ietf-dnsop-qname-minimisation-04.txt 
Domain Name System Operations (dnsop) Working Group S. Bortzmeyer Domain Name System Operations (dnsop) Working Group S. Bortzmeyer
Internet-Draft AFNIC Internet-Draft AFNIC
Intended status: Experimental June 7, 2015 Intended status: Experimental June 19, 2015
Expires: December 9, 2015 Expires: December 21, 2015
DNS query name minimisation to improve privacy DNS query name minimisation to improve privacy
draft-ietf-dnsop-qname-minimisation-03 draft-ietf-dnsop-qname-minimisation-04
Abstract Abstract
This document describes one of the techniques that could be used to This document describes one of the techniques that could be used to
improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a
technique called "QNAME minimisation", where the DNS resolver no technique called "QNAME minimisation", where the DNS resolver no
longer sends the full original QNAME to the upstream name server. longer sends the full original QNAME to the upstream name server.
REMOVE BEFORE PUBLICATION Discussions of the document should take REMOVE BEFORE PUBLICATION Discussions of the document should take
place on the DNSOP working group mailing list [dnsop]. place on the DNSOP working group mailing list [dnsop].
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 December 9, 2015. This Internet-Draft will expire on December 21, 2015.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 3 2. QNAME minimisation . . . . . . . . . . . . . . . . . . . . . 3
3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 3 3. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Operational considerations . . . . . . . . . . . . . . . . . 5 5. Operational considerations . . . . . . . . . . . . . . . . . 5
6. Performance considerations . . . . . . . . . . . . . . . . . 5 6. Performance considerations . . . . . . . . . . . . . . . . . 5
7. Security considerations . . . . . . . . . . . . . . . . . . . 6 7. Security considerations . . . . . . . . . . . . . . . . . . . 6
8. Implementation status - REMOVE BEFORE PUBLICATION . . . . . . 6 8. Implementation status - REMOVE BEFORE PUBLICATION . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. An algorithm to find the zone cut . . . . . . . . . 9 Appendix A. An algorithm to find the zone cut . . . . . . . . . 9
Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
The problem statement is exposed in The problem statement is exposed in
[I-D.ietf-dprive-problem-statement] TODO: add a reference to the [I-D.ietf-dprive-problem-statement] TODO: add a reference to the
specific section when ietf-dprive-problem-statement will be published specific section when ietf-dprive-problem-statement will be published
as RFC. The terminology ("QNAME", "resolver", etc) is also defined as RFC. The terminology ("QNAME", "resolver", etc) is also defined
in this companion document. This specific solution is not intended in this companion document. This specific solution is not intended
to fully solve the DNS privacy problem; instead, it should be viewed to fully solve the DNS privacy problem; instead, it should be viewed
as one tool amongst many. as one tool amongst many.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
the QNAME which is the original QNAME, stripped to just one label the QNAME which is the original QNAME, stripped to just one label
more than the zone for which the server is authoritative. more than the zone for which the server is authoritative.
For example, a resolver receives a request to resolve For example, a resolver receives a request to resolve
foo.bar.baz.example. Let's assume it already knows that foo.bar.baz.example. Let's assume it already knows that
ns1.nic.example is authoritative for .example and the resolver does ns1.nic.example is authoritative for .example and the resolver does
not know a more specific authoritative name server. It will send the not know a more specific authoritative name server. It will send the
query QTYPE=NS,QNAME=baz.example to ns1.nic.example. query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
To do such minimisation, the resolver needs to know the zone cut The minimising resolver works perfectly when it knows the zone cut
[RFC2181]. Zone cuts do not necessarily exist at every label [RFC2181] (section 6). But zone cuts do not necessarily exist at
boundary. If we take the name www.foo.bar.example, it is possible every label boundary. If we take the name www.foo.bar.example, it is
that there is a zone cut between "foo" and "bar" but not between possible that there is a zone cut between "foo" and "bar" but not
"bar" and "example". So, assuming the resolver already knows the between "bar" and "example". So, assuming the resolver already knows
name servers of .example, when it receives the query "What is the the name servers of .example, when it receives the query "What is the
AAAA record of www.foo.bar.example", it does not always know whether AAAA record of www.foo.bar.example", it does not always know where
the request should be sent to the name servers of bar.example or to the zone cut will be. To find it out, it will query the .example
those of example. [RFC2181] suggests a method to find the zone cut name servers for the NS records for bar.example. It will get a
(section 6), so resolvers may try it. NODATA response, indicating there is no zone cut at that point, so it
has to to query the .example name servers again with one more label,
and so on. (Appendix A describes this algorithm in deeper details.)
Since the information about the zone cuts will be stored in the
resolver's cache, the performance cost is probably reasonable.
Section 6 discusses this performance discrepancy further.
Note that DNSSEC-validating resolvers already have access to this Note that DNSSEC-validating resolvers already have access to this
information, since they have to find the zone cut (the DNSKEY record information, since they have to know the zone cut (the DNSKEY record
set is just below, the DS record set just above). set is just below, the DS record set just above).
3. Possible issues 3. Possible issues
QNAME minimisation is legal, since the original DNS RFC do not QNAME minimisation is legal, since the original DNS RFC do not
mandate sending the full QNAME. So, in theory, it should work mandate sending the full QNAME. So, in theory, it should work
without any problems. However, in practice, some problems may occur without any problems. However, in practice, some problems may occur
(see an analysis in [huque-qnamemin]). (see an analysis in [huque-qnamemin]).
Some broken name servers do not react properly to qtype=NS requests. Some broken name servers do not react properly to qtype=NS requests.
skipping to change at page 5, line 13 skipping to change at page 5, line 19
just tell the prospective customer to point their NS records at the just tell the prospective customer to point their NS records at the
hoster's nameservers, and the Web hoster doesn't have to provision hoster's nameservers, and the Web hoster doesn't have to provision
anything in order to make the customer's domain resolve. NS queries anything in order to make the customer's domain resolve. NS queries
to the hoster will therefore do not give the right result, which may to the hoster will therefore do not give the right result, which may
endanger QNAME minimisation (it will be a problem for DNSSEC, too). endanger QNAME minimisation (it will be a problem for DNSSEC, too).
4. Discussion 4. Discussion
QNAME minimisation is compatible with the current DNS system and QNAME minimisation is compatible with the current DNS system and
therefore can easily be deployed; since it is a unilateral change to therefore can easily be deployed; since it is a unilateral change to
the resolver, it does not change the protocol. (Because of that, the resolver, it does not change the protocol. (Because it is an
resolver implementers may do QNAME minimisation in slightly different unilateral change, resolver implementers may do QNAME minimisation in
ways, see the appendices for examples.). slightly different ways, see the appendices for examples.)
One should note that the behaviour suggested here (minimising the One should note that the behaviour suggested here (minimising the
amount of data sent in QNAMEs from the resolver) is NOT forbidden by amount of data sent in QNAMEs from the resolver) is NOT forbidden by
the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). As said in the [RFC1034] (section 5.3.3) or [RFC1035] (section 7.2). As said in
Section 1, the current method, sending the full QNAME, is not Section 1, the current method, sending the full QNAME, is not
mandated by the DNS protocol. mandated by the DNS protocol.
It may be noticed that many documents explaining the DNS and intended It may be noticed that many documents explaining the DNS and intended
for a wide audience, incorrectly describe the resolution process as for a wide audience, incorrectly describe the resolution process as
using QNAME minimisation, for instance by showing a request going to using QNAME minimisation, for instance by showing a request going to
skipping to change at page 6, line 17 skipping to change at page 6, line 23
QNAME minimisation may also improve look-up performance for TLD QNAME minimisation may also improve look-up performance for TLD
operators. For a typical TLD, delegation-only, and with delegations operators. For a typical TLD, delegation-only, and with delegations
just under the TLD, a 2-label QNAME query is optimal for finding the just under the TLD, a 2-label QNAME query is optimal for finding the
delegation owner name. delegation owner name.
QNAME minimisation can decrease performance in some cases, for QNAME minimisation can decrease performance in some cases, for
instance for a deep domain name (like instance for a deep domain name (like
www.host.group.department.example.com where www.host.group.department.example.com where
host.group.department.example.com is hosted on example.com's name host.group.department.example.com is hosted on example.com's name
servers). For such a name, a cold resolver will, depending how QNAME servers). Let's assume a resolver which knows only the name servers
minimisation is implemented, send more queries. Once the cache is of .example. Without QNAME minimisation, it would send these
warm, there will be no difference with a traditional resolver. A .example nameservers a query for
possible solution is to always use the traditional algorithm when the www.host.group.department.example.com and immediately get a specific
cache is cold and then to move to QNAME minimisation. This will referral or an answer, without the need for more queries to probe for
decrease the privacy a bit but will guarantee no degradation of the zone cut. For such a name, a cold resolver with QNAME
performance. Actual testing is described in [huque-qnamemin]. Such minimisation will, depending how QNAME minimisation is implemented,
deep domains are specially common under ip6.arpa. send more queries, one per label. Once the cache is warm, there will
be no difference with a traditional resolver. A possible solution is
to always use the traditional algorithm when the cache is cold and
then to move to QNAME minimisation. This will decrease the privacy a
bit but will guarantee no degradation of performance. Actual testing
is described in [huque-qnamemin]. Such deep domains are specially
common under ip6.arpa.
7. Security considerations 7. Security considerations
QNAME minimisation's benefits are clear in the case where you want to QNAME minimisation's benefits are clear in the case where you want to
decrease exposure to the authoritative name server. But minimising decrease exposure to the authoritative name server. But minimising
the amount of data sent also, in part, addresses the case of a wire the amount of data sent also, in part, addresses the case of a wire
sniffer as well the case of privacy invasion by the servers. sniffer as well the case of privacy invasion by the servers.
(Encryption is of course a better defense against wire sniffers but, (Encryption is of course a better defense against wire sniffers but,
unlike QNAME minimisation, it changes the protocol and cannot be unlike QNAME minimisation, it changes the protocol and cannot be
deployed unilaterally. Also, the effect of QNAME minimisation on deployed unilaterally. Also, the effect of QNAME minimisation on
skipping to change at page 7, line 35 skipping to change at page 7, line 47
described in [huque-qnamemin]. described in [huque-qnamemin].
9. Acknowledgments 9. Acknowledgments
Thanks to Olaf Kolkman for the original idea although the concept is Thanks to Olaf Kolkman for the original idea although the concept is
probably much older [5]. Thanks for Shumon Huque for implementation probably much older [5]. Thanks for Shumon Huque for implementation
and testing. Thanks to Mark Andrews and Francis Dupont for the and testing. Thanks to Mark Andrews and Francis Dupont for the
interesting discussions. Thanks to Brian Dickson, Warren Kumari, interesting discussions. Thanks to Brian Dickson, Warren Kumari,
Evan Hunt and David Conrad for remarks and suggestions. Thanks to Evan Hunt and David Conrad for remarks and suggestions. Thanks to
Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone
cut algorithm in Appendix A. Thanks to Paul Vixie for pointing out cut algorithm in Appendix A and for discussion of the algorithm.
that there are practical advantages (besides privacy) to QNAME Thanks to Paul Vixie for pointing out that there are practical
minimisation. Thanks to Phillip Hallam-Baker for the fallback on A advantages (besides privacy) to QNAME minimisation. Thanks to
queries, to deal with broken servers. Thanks to Robert Edmonds for Phillip Hallam-Baker for the fallback on A queries, to deal with
an interesting anti-pattern. broken servers. Thanks to Robert Edmonds for an interesting anti-
pattern.
10. References 10. References
10.1. Normative References 10.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.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July Considerations for Internet Protocols", RFC 6973, July
2013. 2013.
[I-D.ietf-dprive-problem-statement] [I-D.ietf-dprive-problem-statement]
Bortzmeyer, S., "DNS privacy considerations", draft-ietf- Bortzmeyer, S., "DNS privacy considerations", draft-ietf-
dprive-problem-statement-05 (work in progress), May 2015. dprive-problem-statement-06 (work in progress), June 2015.
10.2. Informative References 10.2. Informative References
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July Code: The Implementation Status Section", RFC 6982, July
2013. 2013.
 End of changes. 13 change blocks. 
37 lines changed or deleted 50 lines changed or added

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