idnits 2.17.1 draft-bortzmeyer-dns-qname-minimisation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.bortzmeyer-dnsop-dns-privacy]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 177, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bortzmeyer-dnsop-dns-privacy-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Informational May 19, 2014 5 Expires: November 20, 2014 7 DNS query name minimisation to improve privacy 8 draft-bortzmeyer-dns-qname-minimisation-02 10 Abstract 12 This document describes one of the techniques that could be used to 13 improve DNS privacy (see [I-D.bortzmeyer-dnsop-dns-privacy]), a 14 technique called "qname minimisation". 16 Discussions of the document should currently take place on the dns- 17 privacy mailing list [dns-privacy]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 20, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and background . . . . . . . . . . . . . . . . . 2 54 2. Qname minimisation . . . . . . . . . . . . . . . . . . . . . 2 55 3. Operational considerations . . . . . . . . . . . . . . . . . 3 56 4. Other advantages . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security considerations . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 7.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Appendix A. An algorithm to find the zone cut . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction and background 67 The problem statement is exposed in 68 [I-D.bortzmeyer-dnsop-dns-privacy]. The terminology ("qname", 69 "resolver", etc) is also defined in this companion document. This 70 specific solution is not intended to completely solve the problem, 71 far from it. It is better to see it as one tool among a toolbox. 73 It follows the principle explained in section 6.1 of [RFC6973]: the 74 less data you send out, the less privacy problems you'll get. 76 2. Qname minimisation 78 The idea is to minimise the amount of data sent from the DNS 79 resolver. When a resolver receives the query "What is the AAAA 80 record for www.example.com?", it sends to the root (assuming a cold 81 resolver, whose cache is empty) the very same question. Sending 82 "What are the NS records for .com?" would be sufficient (since it 83 will be the answer from the root anyway). To do so would be 84 compatible with the current DNS system and therefore could be easily 85 deployable, since it is an unilateral change to the resolvers. 87 If "minimisation" is too long, you can write it "m12n". 89 To do such minimisation, the resolver needs to know the zone cut 90 [RFC2181]. There is not a zone cut at every label boundary. If we 91 take the name www.foo.bar.example, it is possible that there is a 92 zone cut between "foo" and "bar" but not between "bar" and "example". 93 So, assuming the resolver already knows the name servers of .example, 94 when it receives the query "What is the AAAA record of 95 www.foo.bar.example", it does not always know if the request should 96 be sent to the name servers of bar.example or to those of example. 97 [RFC2181] suggests a method to find the zone cut (section 6), so 98 resolvers may try it. 100 Note that DNSSEC-validating resolvers already have access to this 101 information, since they have to find the zone cut (the DNSKEY record 102 set is just below, the DS record set just above). 104 It can be noted that minimising the amount of data sent also 105 partially addresses the case of a wire sniffer, not just the case of 106 privacy invasion by the servers. 108 One should note that the behaviour suggested here (minimising the 109 amount of data sent in qnames) is NOT forbidden by the [RFC1034] 110 (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname 111 to the authoritative name server is a tradition, not a protocol 112 requirment. 114 3. Operational considerations 116 The administrators of the forwarders, and of the authoritative name 117 servers, will get less data, which will reduce the utility of the 118 statistics they can produce (such as the percentage of the various 119 qtypes). On the other hand, it will decrease their legal 120 responsability, in many cases. 122 Some broken name servers do not react properly to qtype=NS requests. 123 As an example, look at www.ratp.fr (not ratp.fr), which is delegated 124 to two name servers that reply properly to "A www.ratp.fr" queries 125 but send REFUSED to queries "NS www.ratp.fr". This behaviour is a 126 gross protocol violation and there is no need to stop improving the 127 DNS because of such brokenness. However, qname minimisation may 128 still work with such domains since they are only leaf domains (no 129 need to send them NS requests). 131 Another way to deal with such broken name servers would be to try 132 with A requests (A being choosen because it is the most common and 133 hence the least revealing qtype). Instead of querying name servers 134 with a query "NS example.com", we could use "A _.example.com" and see 135 if we get a referral. 137 4. Other advantages 139 The main goal of qname minimisation is to improve privacy, by sending 140 less data. However, it may have other advantages. For instance, if 141 a root name server receives a query from some resolver for A.CORP 142 followed by B.CORP followed by C.CORP, the result will be three 143 NXDOMAINs, since .CORP does not exist in the root zone. Under query 144 minimization, the root name servers would hear only one question (for 145 .CORP itself) to which they could answer NXDOMAIN, thus opening up a 146 negative caching opportunity in which the full resolver could know a 147 priori that neither B.CORP or C.CORP could exist. Thus in this 148 common case the total number of upstream queries under query 149 minimisation would be counter-intuitively less than the number of 150 queries under the traditional iteration (as described in the DNS 151 standard). 153 5. Security considerations 155 Under study. TODO: better handling of phantom domains? 157 6. Acknowledgments 159 Thanks to Olaf Kolkman, Mark Andrews and Francis Dupont for the 160 interesting discussions on this qname minimisation. Thanks to Mohsen 161 Souissi for proofreading. Thanks to Tony Finch for the zone cut 162 algorithm in Appendix A. Thanks to Paul Vixie for pointing out that 163 there are practical advantages (besides privacy) to qname m12n. 164 Thanks to Phillip Hallam-Baker for the fallback on A queries, to deal 165 with broken servers. 167 7. References 169 7.1. Normative References 171 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 172 STD 13, RFC 1034, November 1987. 174 [RFC1035] Mockapetris, P., "Domain names - implementation and 175 specification", STD 13, RFC 1035, November 1987. 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 181 Morris, J., Hansen, M., and R. Smith, "Privacy 182 Considerations for Internet Protocols", RFC 6973, July 183 2013. 185 [I-D.bortzmeyer-dnsop-dns-privacy] 186 Bortzmeyer, S., "DNS privacy problem statement", draft- 187 bortzmeyer-dnsop-dns-privacy-01 (work in progress), 188 December 2013. 190 7.2. Informative References 192 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 193 Specification", RFC 2181, July 1997. 195 [dns-privacy] 196 IETF, , "The dns-privacy mailing list", March 2014. 198 Appendix A. An algorithm to find the zone cut 200 Although a validating resolver already has the logic to find the zone 201 cut, other resolvers may be interested by this algorithm to follow in 202 order to locate this cut: 204 (0) If the query can be answered from the cache, do so, otherwise 205 iterate as follows: 207 (1) Find closest enclosing NS RRset in your cache. The owner of 208 this NS RRset will be a suffix of the QNAME - the longest suffix 209 of any NS RRset in the cache. Call this PARENT. 211 (2) Initialize CHILD to the same as PARENT. 213 (3) If CHILD is the same as the QNAME, resolve the original query 214 using PARENT's name servers, and finish. 216 (4) Otherwise, add a label from the QNAME to the start of CHILD. 218 (5) If you have a negative cache entry for the NS RRset at CHILD, 219 go back to step 3. 221 (6) Query for CHILD IN NS using PARENT's name servers. The 222 response can be: 224 (6a) A referral. Cache the NS RRset from the authority section 225 and go back to step 1. 227 (6b) An authoritative answer. Cache the NS RRset from the 228 answer section and go back to step 1. 230 (6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response 231 to the original query and stop. 233 (6d) A NOERROR/NODATA answer. Cache this negative answer and 234 go back to step 3. 236 Author's Address 238 Stephane Bortzmeyer 239 AFNIC 240 1, rue Stephenson 241 Montigny-le-Bretonneux 78180 242 France 244 Phone: +33 1 39 30 83 46 245 Email: bortzmeyer+ietf@nic.fr 246 URI: http://www.afnic.fr/