idnits 2.17.1 draft-ietf-dnsop-qname-minimisation-01.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.ietf-dprive-problem-statement]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 294 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-problem-statement-01 == Outdated reference: A later version (-03) exists of draft-wkumari-dnsop-hammer-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations (dnsop) Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Experimental February 15, 2015 5 Expires: August 19, 2015 7 DNS query name minimisation to improve privacy 8 draft-ietf-dnsop-qname-minimisation-01 10 Abstract 12 This document describes one of the techniques that could be used to 13 improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a 14 technique called "qname minimisation". 16 Discussions of the document should take place on the DNSOP working 17 group mailing list [dnsop]. 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 August 19, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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. Performance implications . . . . . . . . . . . . . . . . . . 5 57 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Appendix A. An algorithm to find the zone cut . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction and background 68 The problem statement is exposed in 69 [I-D.ietf-dprive-problem-statement] TODO: add a reference to the 70 specific section when ietf-dprive-problem-statement will be published 71 as RFC. The terminology ("qname", "resolver", etc) is also defined 72 in this companion document. This specific solution is not intended 73 to fully solve the DNS privacy problem; instead, it should be viewed 74 as one tool amongst many. 76 It follows the principle explained in section 6.1 of [RFC6973]: the 77 less data you send out, the less privacy problems you'll get. 79 2. Qname minimisation 81 The idea is to minimise the amount of data sent from the DNS 82 resolver. When a resolver receives the query "What is the AAAA 83 record for www.example.com?", it sends to the root (assuming a cold 84 resolver, whose cache is empty) the very same question. Sending 85 "What are the NS records for .com?" would be sufficient (since it 86 will be the answer from the root anyway). To do so would be 87 compatible with the current DNS system and therefore could be easily 88 deployable, since it is an unilateral change to the resolvers, it 89 does not change the protocol. Because of that, resolver implementers 90 may do qname minmisation in slightly different ways. 92 If "minimisation" is too long, you can write it "m10n". 94 To do such minimisation, the resolver needs to know the zone cut 95 [RFC2181]. Zone cuts do not necessarily exist at every label 96 boundary. If we take the name www.foo.bar.example, it is possible 97 that there is a zone cut between "foo" and "bar" but not between 98 "bar" and "example". So, assuming the resolver already knows the 99 name servers of .example, when it receives the query "What is the 100 AAAA record of www.foo.bar.example", it does not always know if the 101 request should be sent to the name servers of bar.example or to those 102 of example. [RFC2181] suggests a method to find the zone cut 103 (section 6), so resolvers may try it. 105 Note that DNSSEC-validating resolvers already have access to this 106 information, since they have to find the zone cut (the DNSKEY record 107 set is just below, the DS record set just above). 109 Minimising the amount of data sent also, in part, addresses the case 110 of a wire sniffer as well the case of privacy invasion by the 111 servers. 113 One should note that the behaviour suggested here (minimising the 114 amount of data sent in qnames) is NOT forbidden by the [RFC1034] 115 (section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname 116 to the authoritative name server is a tradition, not a protocol 117 requirment. This tradition comes[mockapetris-history] from a desire 118 to optimize the number of requests, when the same name server is 119 authoritative for many zones in a given name (something which was 120 more common in the old days, where the same name servers served .com 121 and the root) or when the same name server is both recursive and 122 authoritative (something which is strongly discouraged now). 123 Whatever the merits of this choice at this time, the DNS is quite 124 different now. 126 As mentioned before, there are several ways to implement qname 127 minimisation. Two main strategies are the aggressive one and the 128 lazy one. In the aggressive one, the resolver only sends NS queries 129 as long as it does not know the zone cuts. This is the safest, from 130 a privacy point of view. The lazy way "piggybacks" on the 131 traditional resolution code. It sends traditional full qnames and 132 learn the zone cuts from the referrals received, then switching to NS 133 queries. This leaks more data but probably requires less changes in 134 the existing resolver codebase. 136 3. Operational considerations 138 The administrators of the forwarders, and of the authoritative name 139 servers, will get less data, which will reduce the utility of the 140 statistics they can produce (such as the percentage of the various 141 qtypes). On the other hand, it may decrease their legal 142 responsibility. 144 Some broken name servers do not react properly to qtype=NS requests. 145 For instance, some authoritative name servers embedded in load 146 balancers reply properly to A queries but send REFUSED to NS queries. 147 REMOVE THIS SENTENCE BEFORE PUBLICATION: As an example of today, look 148 at www.ratp.fr (not ratp.fr). This behaviour is a gross protocol 149 violation, and there is no need to stop improving the DNS because of 150 such brokenness. However, qname minimisation may still work with 151 such domains since they are only leaf domains (no need to send them 152 NS requests). Such setup breaks more than just qname minimisation. 153 It breaks negative answers, since the servers don't return the 154 correct SOA, and it also breaks anything dependent upon NS and SOA 155 records existing at the top of the zone. 157 A problem can also appear when a name server does not react properly 158 to ENT (Empty Non-Terminals). If ent.example.com has no resource 159 records but foobar.ent.example.com does, then ent.example.com is an 160 ENT. A query, whatever the qtype, for ent.example.com must return 161 NODATA (NOERROR / ANSWER: 0). However, some broken name servers 162 return NXDOMAIN for ENTs. REMOVE THIS SENTENCE BEFORE PUBLICATION: 163 As an example of today, look at com.akadns.net or www.upenn.edu with 164 its delegations to Akamai. If a resolver queries only 165 foobar.ent.example.com, everything will be OK but, if it implements 166 qname minimisation, it may query ent.example.com and get a NXDOMAIN. 167 See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad 168 consequences of this brokenness. 170 Another way to deal with such broken name servers would be to try 171 with A requests (A being chosen because it is the most common and 172 hence a qtype which will be always accepted, while a qtype NS may 173 ruffle the feathers of some middleboxes). Instead of querying name 174 servers with a query "NS example.com", we could use "A _.example.com" 175 and see if we get a referral. 177 Other strange and illegal practices may pose a problem: for instance, 178 there is a common DNS anti-pattern used by low-end web hosters that 179 also do DNS hosting that exploits the fact that the DNS protocol 180 (pre-DNSSEC) allows certain serious misconfigurations, such as parent 181 and child zones disagreeing on the location of a zone cut. 182 Basically, they have a single zone with wildcards like: 184 *.example. 60 IN A 192.0.2.6 186 (It is not known why they don't just wildcard all of "*." and be done 187 with it.) 189 This lets them turn up tons of web hosting customers without having 190 to configure thousands of individual zones on their nameservers. 191 They just tell the prospective customer to point their NS records at 192 their nameservers, and the Web hoster doesn't have to provision 193 anything in order to make the customer's domain resolve. 195 Qname minimisation can decrease performance in some cases, for 196 instance for a deep domain name (like 197 www.host.group.department.example.com where 198 host.group.department.example.com is hosted on example.com's name 199 servers). For such a name, a cold resolver will, depending how qname 200 minimisation is implemented, send more queries. Once warm, there 201 will be no difference with a traditional resolver. A possible 202 solution is to always use the traditional algorithm when the cache is 203 cold and then to move to qname minimisation. This will decrease the 204 privacy a bit but will guarantee no degradation of performance. 206 Another useful optimisation may be, in the spirit of the HAMMER idea 207 [I-D.wkumari-dnsop-hammer] to probe in advance for the introduction 208 of zone cuts where none previously existed (i.e. confirm their 209 continued absence, or discover them.) 211 4. Performance implications 213 The main goal of qname minimisation is to improve privacy by sending 214 less data. However, it may have other advantages. For instance, if 215 a root name server receives a query from some resolver for A.CORP 216 followed by B.CORP followed by C.CORP, the result will be three 217 NXDOMAINs, since .CORP does not exist in the root zone. Under query 218 name minimisation, the root name servers would hear only one question 219 (for .CORP itself) to which they could answer NXDOMAIN, thus opening 220 up a negative caching opportunity in which the full resolver could 221 know a priori that neither B.CORP or C.CORP could exist. Thus in 222 this common case the total number of upstream queries under qname 223 minimisation would be counter-intuitively less than the number of 224 queries under the traditional iteration (as described in the DNS 225 standard). 227 Qname minimisation may also improve look-up performance for TLD 228 operators. For a typical TLD, delegation-only, and with delegations 229 just under the TLD, a 2-label QNAME query is optimal for finding the 230 delegation owner name. 232 5. Security considerations 234 No security consequence (besides privacy improvment) is known at this 235 time. 237 6. Acknowledgments 239 Thanks to Olaf Kolkman for the original idea although the concept is 240 probably much older [1]. Thanks to Mark Andrews and Francis Dupont 241 for the interesting discussions. Thanks to Brian Dickson, Warren 242 Kumari and David Conrad for remarks and suggestions. Thanks to 243 Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone 244 cut algorithm in Appendix A. Thanks to Paul Vixie for pointing out 245 that there are practical advantages (besides privacy) to qname m10n. 246 Thanks to Phillip Hallam-Baker for the fallback on A queries, to deal 247 with broken servers. Thanks to Robert Edmonds for an interesting 248 anti-pattern. 250 7. References 252 7.1. Normative References 254 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 255 STD 13, RFC 1034, November 1987. 257 [RFC1035] Mockapetris, P., "Domain names - implementation and 258 specification", STD 13, RFC 1035, November 1987. 260 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 261 Morris, J., Hansen, M., and R. Smith, "Privacy 262 Considerations for Internet Protocols", RFC 6973, July 263 2013. 265 [I-D.ietf-dprive-problem-statement] 266 Bortzmeyer, S., "DNS privacy considerations", draft-ietf- 267 dprive-problem-statement-01 (work in progress), January 268 2015. 270 7.2. Informative References 272 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 273 Specification", RFC 2181, July 1997. 275 [I-D.wkumari-dnsop-hammer] 276 Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly 277 Automated Method for Maintaining Expiring Records", draft- 278 wkumari-dnsop-hammer-01 (work in progress), July 2014. 280 [I-D.vixie-dnsext-resimprove] 281 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 282 Resolvers for Resiliency, Robustness, and Responsiveness", 283 draft-vixie-dnsext-resimprove-00 (work in progress), June 284 2010. 286 [dnsop] IETF, , "The DNSOP working group of IETF", March 2014, 287 . 289 [mockapetris-history] 290 Mockapetris, P., "Private discussion", January 2015. 292 7.3. URIs 294 [1] https://lists.dns-oarc.net/pipermail/dns- 295 operations/2010-February/005003.html 297 Appendix A. An algorithm to find the zone cut 299 Although a validating resolver already has the logic to find the zone 300 cut, other resolvers may be interested by this algorithm to follow in 301 order to locate this cut: 303 (0) If the query can be answered from the cache, do so, otherwise 304 iterate as follows: 306 (1) Find closest enclosing NS RRset in your cache. The owner of 307 this NS RRset will be a suffix of the QNAME - the longest suffix 308 of any NS RRset in the cache. Call this PARENT. 310 (2) Initialize CHILD to the same as PARENT. 312 (3) If CHILD is the same as the QNAME, resolve the original query 313 using PARENT's name servers, and finish. 315 (4) Otherwise, add a label from the QNAME to the start of CHILD. 317 (5) If you have a negative cache entry for the NS RRset at CHILD, 318 go back to step 3. 320 (6) Query for CHILD IN NS using PARENT's name servers. The 321 response can be: 323 (6a) A referral. Cache the NS RRset from the authority section 324 and go back to step 1. 326 (6b) An authoritative answer. Cache the NS RRset from the 327 answer section and go back to step 1. 329 (6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response 330 to the original query and stop. 332 (6d) A NOERROR/NODATA answer. Cache this negative answer and 333 go back to step 3. 335 Author's Address 337 Stephane Bortzmeyer 338 AFNIC 339 1, rue Stephenson 340 Montigny-le-Bretonneux 78180 341 France 343 Phone: +33 1 39 30 83 46 344 Email: bortzmeyer+ietf@nic.fr 345 URI: http://www.afnic.fr/