1 Internet Engineering Task Force (IETF) S. Bortzmeyer
2 Request for Comments: 7816 AFNIC
3 Category: Experimental March 2016
4 ISSN: 2070-1721
5
6
7 DNS Query Name Minimisation to Improve Privacy
8
9 Abstract
10
11 This document describes a technique to improve DNS privacy, a
12 technique called "QNAME minimisation", where the DNS resolver no
13 longer sends the full original QNAME to the upstream name server.
14
15 Status of This Memo
16
17 This document is not an Internet Standards Track specification; it is
18 published for examination, experimental implementation, and
19 evaluation.
20
21 This document defines an Experimental Protocol for the Internet
22 community. This document is a product of the Internet Engineering
23 Task Force (IETF). It represents the consensus of the IETF
24 community. It has received public review and has been approved for
25 publication by the Internet Engineering Steering Group (IESG). Not
26 all documents approved by the IESG are a candidate for any level of
27 Internet Standard; see Section 2 of RFC 5741.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 http://www.rfc-editor.org/info/rfc7816.
32
33 Copyright Notice
34
35 Copyright (c) 2016 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
47
48
49
50
51
52 Bortzmeyer Experimental [Page 1]
53 RFC 7816 QNAME Minimisation March 2016
54
55
56 Table of Contents
57
58 1. Introduction and Background .....................................2
59 2. QNAME Minimisation ..............................................3
60 3. Possible Issues .................................................4
61 4. Protocol and Compatibility Discussion ...........................5
62 5. Operational Considerations ......................................5
63 6. Performance Considerations ......................................6
64 7. On the Experimentation ..........................................6
65 8. Security Considerations .........................................7
66 9. References ......................................................7
67 9.1. Normative References .......................................7
68 9.2. Informative References .....................................8
69 Appendix A. An Algorithm to Perform QNAME Minimisation .............9
70 Appendix B. Alternatives .........................................10
71 Acknowledgments ...................................................11
72 Author's Address ..................................................11
73
74 1. Introduction and Background
75
76 The problem statement is described in [RFC7626]. The terminology
77 ("QNAME", "resolver", etc.) is also defined in this companion
78 document. This specific solution is not intended to fully solve
79 the DNS privacy problem; instead, it should be viewed as one tool
80 amongst many.
81
82 QNAME minimisation follows the principle explained in Section 6.1 of
83 [RFC6973]: the less data you send out, the fewer privacy problems
84 you have.
85
86 Currently, when a resolver receives the query "What is the AAAA
87 record for www.example.com?", it sends to the root (assuming a cold
88 resolver, whose cache is empty) the very same question. Sending the
89 full QNAME to the authoritative name server is a tradition, not a
90 protocol requirement. In a conversation with the author in
91 January 2015, Paul Mockapetris explained that this tradition comes
92 from a desire to optimise the number of requests, when the same
93 name server is authoritative for many zones in a given name
94 (something that was more common in the old days, where the same
95 name servers served .com and the root) or when the same name server
96 is both recursive and authoritative (something that is strongly
97 discouraged now). Whatever the merits of this choice at this time,
98 the DNS is quite different now.
99
100
101
102
103
104
105
106
107 Bortzmeyer Experimental [Page 2]
108 RFC 7816 QNAME Minimisation March 2016
109
110
111 2. QNAME Minimisation
112
113 The idea is to minimise the amount of data sent from the DNS resolver
114 to the authoritative name server. In the example in the previous
115 section, sending "What are the NS records for .com?" would have been
116 sufficient (since it will be the answer from the root anyway). The
117 rest of this section describes the recommended way to do QNAME
118 minimisation -- the way that maximises privacy benefits (other
119 alternatives are discussed in the appendices).
120
121 Instead of sending the full QNAME and the original QTYPE upstream, a
122 resolver that implements QNAME minimisation and does not already have
123 the answer in its cache sends a request to the name server
124 authoritative for the closest known ancestor of the original QNAME.
125 The request is done with:
126
127 o the QTYPE NS
128
129 o the QNAME that is the original QNAME, stripped to just one label
130 more than the zone for which the server is authoritative
131
132 For example, a resolver receives a request to resolve
133 foo.bar.baz.example. Let's assume that it already knows that
134 ns1.nic.example is authoritative for .example and the resolver does
135 not know a more specific authoritative name server. It will send the
136 query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
137
138 The minimising resolver works perfectly when it knows the zone cut
139 (zone cuts are described in Section 6 of [RFC2181]). But zone cuts
140 do not necessarily exist at every label boundary. If we take the
141 name www.foo.bar.example, it is possible that there is a zone cut
142 between "foo" and "bar" but not between "bar" and "example". So,
143 assuming that the resolver already knows the name servers of
144 .example, when it receives the query "What is the AAAA record of
145 www.foo.bar.example?", it does not always know where the zone cut
146 will be. To find the zone cut, it will query the .example
147 name servers for the NS records for bar.example. It will get a
148 NODATA response, indicating that there is no zone cut at that point,
149 so it has to query the .example name servers again with one more
150 label, and so on. (Appendix A describes this algorithm in deeper
151 detail.)
152
153 Since the information about the zone cuts will be stored in the
154 resolver's cache, the performance cost is probably reasonable.
155 Section 6 discusses this performance discrepancy further.
156
157
158
159
160
161
162 Bortzmeyer Experimental [Page 3]
163 RFC 7816 QNAME Minimisation March 2016
164
165
166 Note that DNSSEC-validating resolvers already have access to this
167 information, since they have to know the zone cut (the DNSKEY record
168 set is just below; the DS record set is just above).
169
170 3. Possible Issues
171
172 QNAME minimisation is legal, since the original DNS RFCs do not
173 mandate sending the full QNAME. So, in theory, it should work
174 without any problems. However, in practice, some problems may occur
175 (see [Huque-QNAME-Min] for an analysis and [Huque-QNAME-storify] for
176 an interesting discussion on this topic).
177
178 Some broken name servers do not react properly to QTYPE=NS requests.
179 For instance, some authoritative name servers embedded in load
180 balancers reply properly to A queries but send REFUSED to NS queries.
181 This behaviour is a protocol violation, and there is no need to stop
182 improving the DNS because of such behaviour. However, QNAME
183 minimisation may still work with such domains, since they are only
184 leaf domains (no need to send them NS requests). Such a setup breaks
185 more than just QNAME minimisation. It breaks negative answers, since
186 the servers don't return the correct SOA, and it also breaks anything
187 dependent upon NS and SOA records existing at the top of the zone.
188
189 Another way to deal with such incorrect name servers would be to try
190 with QTYPE=A requests (A being chosen because it is the most common
191 and hence a QTYPE that will always be accepted, while a QTYPE NS may
192 ruffle the feathers of some middleboxes). Instead of querying
193 name servers with a query "NS example.com", we could use
194 "A _.example.com" and see if we get a referral.
195
196 A problem can also appear when a name server does not react properly
197 to ENTs (Empty Non-Terminals). If ent.example.com has no resource
198 records but foobar.ent.example.com does, then ent.example.com is an
199 ENT. Whatever the QTYPE, a query for ent.example.com must return
200 NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly
201 return NXDOMAIN for ENTs. If a resolver queries only
202 foobar.ent.example.com, everything will be OK, but if it implements
203 QNAME minimisation, it may query ent.example.com and get an NXDOMAIN.
204 See also Section 3 of [DNS-Res-Improve] for the other bad
205 consequences of this bad behaviour.
206
207 A possible solution, currently implemented in Knot, is to retry with
208 the full query when you receive an NXDOMAIN. It works, but it is not
209 ideal for privacy.
210
211 Other practices that do not conform to the DNS protocol standards may
212 pose a problem: there is a common DNS trick used by some web hosters
213 that also do DNS hosting that exploits the fact that the DNS protocol
214
215
216
217 Bortzmeyer Experimental [Page 4]
218 RFC 7816 QNAME Minimisation March 2016
219
220
221 (pre-DNSSEC) allows certain serious misconfigurations, such as parent
222 and child zones disagreeing on the location of a zone cut.
223 Basically, they have a single zone with wildcards for each TLD, like:
224
225 *.example. 60 IN A 192.0.2.6
226
227 (They could just wildcard all of "*.", which would be sufficient. We
228 don't know why they don't do it.)
229
230 This lets them have many web-hosting customers without having to
231 configure thousands of individual zones on their name servers. They
232 just tell the prospective customer to point their NS records at the
233 hoster's name servers, and the web hoster doesn't have to provision
234 anything in order to make the customer's domain resolve. NS queries
235 to the hoster will therefore not give the right result, which may
236 endanger QNAME minimisation (it will be a problem for DNSSEC, too).
237
238 4. Protocol and Compatibility Discussion
239
240 QNAME minimisation is compatible with the current DNS system and
241 therefore can easily be deployed; since it is a unilateral change to
242 the resolver, it does not change the protocol. (Because it is a
243 unilateral change, resolver implementers may do QNAME minimisation in
244 slightly different ways; see the appendices for examples.)
245
246 One should note that the behaviour suggested here (minimising the
247 amount of data sent in QNAMEs from the resolver) is NOT forbidden by
248 Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035]. As stated in
249 Section 1, the current method, sending the full QNAME, is not
250 mandated by the DNS protocol.
251
252 One may notice that many documents that explain the DNS and that are
253 intended for a wide audience incorrectly describe the resolution
254 process as using QNAME minimisation (e.g., by showing a request going
255 to the root, with just the TLD in the query). As a result, these
256 documents may confuse readers that use them for privacy analysis.
257
258 5. Operational Considerations
259
260 The administrators of the forwarders, and of the authoritative
261 name servers, will get less data, which will reduce the utility of
262 the statistics they can produce (such as the percentage of the
263 various QTYPEs) [Kaliski-Minimum].
264
265 DNS administrators are reminded that the data on DNS requests that
266 they store may have legal consequences, depending on your
267 jurisdiction (check with your local lawyer).
268
269
270
271
272 Bortzmeyer Experimental [Page 5]
273 RFC 7816 QNAME Minimisation March 2016
274
275
276 6. Performance Considerations
277
278 The main goal of QNAME minimisation is to improve privacy by sending
279 less data. However, it may have other advantages. For instance, if
280 a root name server receives a query from some resolver for A.example
281 followed by B.example followed by C.example, the result will be three
282 NXDOMAINs, since .example does not exist in the root zone. Under
283 query name minimisation, the root name servers would hear only one
284 question (for .example itself) to which they could answer NXDOMAIN,
285 thus opening up a negative caching opportunity in which the full
286 resolver could know a priori that neither B.example nor C.example
287 could exist. Thus, in this common case the total number of upstream
288 queries under QNAME minimisation would be counterintuitively less
289 than the number of queries under the traditional iteration (as
290 described in the DNS standard).
291
292 QNAME minimisation may also improve lookup performance for TLD
293 operators. For a typical TLD, delegation-only, and with delegations
294 just under the TLD, a two-label QNAME query is optimal for finding
295 the delegation owner name.
296
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
RFC 7816 was implemented in BIND 9.18 (all versions) and is enabled by default in relaxed mode. See https://bind9.readthedocs.io/en/latest/reference.html?highlight=qname%20minimization#namedconf-statement-qname-minimization. We have had some issues with our implementation, such as https://gitlab.isc.org/isc-projects/bind9/-/issues/3331.
297 QNAME minimisation can decrease performance in some cases -- for
298 instance, for a deep domain name (like
299 www.host.group.department.example.com, where
300 host.group.department.example.com is hosted on example.com's
301 name servers). Let's assume a resolver that knows only the
302 name servers of .example. Without QNAME minimisation, it would send
303 these .example name servers a query for
304 www.host.group.department.example.com and immediately get a specific
305 referral or an answer, without the need for more queries to probe for
306 the zone cut. For such a name, a cold resolver with QNAME
307 minimisation will, depending on how QNAME minimisation is
308 implemented, send more queries, one per label. Once the cache is
309 warm, there will be no difference with a traditional resolver.
310 Actual testing is described in [Huque-QNAME-Min]. Such deep domains
311 are especially common under ip6.arpa.
312
313 7. On the Experimentation
314
315 This document has status "Experimental". Since the beginning of time
316 (or DNS), the fully qualified host name was always sent to the
317 authoritative name servers. There was a concern that changing this
318 behaviour may engage the Law of Unintended Consequences -- hence this
319 status.
320
321 The idea behind the experiment is to observe QNAME minimisation in
322 action with multiple resolvers, various authoritative name servers,
323 etc.
324
325
326
327 Bortzmeyer Experimental [Page 6]
328 RFC 7816 QNAME Minimisation March 2016
329
330
331 8. Security Considerations
332
333 QNAME minimisation's benefits are clear in the case where you want to
334 decrease exposure to the authoritative name server. But minimising
335 the amount of data sent also, in part, addresses the case of a wire
336 sniffer as well as the case of privacy invasion by the servers.
337 (Encryption is of course a better defense against wire sniffers, but,
338 unlike QNAME minimisation, it changes the protocol and cannot be
339 deployed unilaterally. Also, the effect of QNAME minimisation on
340 wire sniffers depends on whether the sniffer is on the DNS path.)
341
342 QNAME minimisation offers zero protection against the recursive
343 resolver, which still sees the full request coming from the stub
344 resolver.
345
346 All the alternatives mentioned in Appendix B decrease privacy in the
347 hope of improving performance. They must not be used if you want
348 maximum privacy.
349
350 9. References
351
352 9.1. Normative References
353
354 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
355 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
356 <http://www.rfc-editor.org/info/rfc1034>.
357
358 [RFC1035] Mockapetris, P., "Domain names - implementation and
359 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
360 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
361
362 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
363 Morris, J., Hansen, M., and R. Smith, "Privacy
364 Considerations for Internet Protocols", RFC 6973,
365 DOI 10.17487/RFC6973, July 2013,
366 <http://www.rfc-editor.org/info/rfc6973>.
367
368 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
369 DOI 10.17487/RFC7626, August 2015,
370 <http://www.rfc-editor.org/info/rfc7626>.
371
372
373
374
375
376
377
378
379
380
381
382 Bortzmeyer Experimental [Page 7]
383 RFC 7816 QNAME Minimisation March 2016
384
385
386 9.2. Informative References
387
388 [DNS-Res-Improve]
389 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
390 Resolvers for Resiliency, Robustness, and Responsiveness",
391 Work in Progress, draft-vixie-dnsext-resimprove-00,
392 June 2010.
393
394 [HAMMER] Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly
395 Automated Method for Maintaining Expiring Records", Work
396 in Progress, draft-wkumari-dnsop-hammer-01, July 2014.
397
398 [Huque-QNAME-Min]
399 Huque, S., "Query name minimization and authoritative
400 server behavior", May 2015,
401 <https://indico.dns-oarc.net/event/21/contribution/9>.
402
403 [Huque-QNAME-storify]
404 Huque, S., "Qname Minimization @ DNS-OARC", May 2015,
405 <https://storify.com/shuque/qname-minimization-dns-oarc>.
406
407 [Kaliski-Minimum]
408 Kaliski, B., "Minimum Disclosure: What Information Does a
409 Name Server Need to Do Its Job?", March 2015,
410 <http://blogs.verisigninc.com/blog/entry/
411 minimum_disclosure_what_information_does>.
412
413 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
414 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
415 <http://www.rfc-editor.org/info/rfc2181>.
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Bortzmeyer Experimental [Page 8]
438 RFC 7816 QNAME Minimisation March 2016
439
440
441 Appendix A. An Algorithm to Perform QNAME Minimisation
442
443 This algorithm performs name resolution with QNAME minimisation in
444 the presence of zone cuts that are not yet known.
445
446 Although a validating resolver already has the logic to find the
447 zone cuts, implementers of other resolvers may want to use this
448 algorithm to locate the cuts. This is just a possible aid for
449 implementers; it is not intended to be normative:
450
451 (0) If the query can be answered from the cache, do so; otherwise,
452 iterate as follows:
453
454 (1) Find the closest enclosing NS RRset in your cache. The owner of
455 this NS RRset will be a suffix of the QNAME -- the longest suffix
456 of any NS RRset in the cache. Call this ANCESTOR.
457
458 (2) Initialise CHILD to the same as ANCESTOR.
459
460 (3) If CHILD is the same as the QNAME, resolve the original query
461 using ANCESTOR's name servers, and finish.
462
463 (4) Otherwise, add a label from the QNAME to the start of CHILD.
464
465 (5) If you have a negative cache entry for the NS RRset at CHILD, go
466 back to step 3.
467
468 (6) Query for CHILD IN NS using ANCESTOR's name servers. The
469 response can be:
470
471 (6a) A referral. Cache the NS RRset from the authority section,
472 and go back to step 1.
473
474 (6b) An authoritative answer. Cache the NS RRset from the
475 answer section, and go back to step 1.
476
477 (6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response
478 to the original query, and stop.
479
480 (6d) A NOERROR/NODATA answer. Cache this negative answer, and
481 go back to step 3.
482
483
484
485
486
487
488
489
490
491
492 Bortzmeyer Experimental [Page 9]
493 RFC 7816 QNAME Minimisation March 2016
494
495
496 Appendix B. Alternatives
497
498 Remember that QNAME minimisation is unilateral, so a resolver is not
499 forced to implement it exactly as described here.
500
501 There are several ways to perform QNAME minimisation. See Section 2
502 for the suggested way. It can be called the aggressive algorithm,
503 since the resolver only sends NS queries as long as it does not know
504 the zone cuts. This is the safest, from a privacy point of view.
505 Another possible algorithm, not fully studied at this time, could be
506 to "piggyback" on the traditional resolution code. At startup, it
507 sends traditional full QNAMEs and learns the zone cuts from the
508 referrals received, then switches to NS queries asking only for the
509 minimum domain name. This leaks more data but could require fewer
510 changes in the existing resolver codebase.
511
512 In the above specification, the original QTYPE is replaced by NS (or
513 may be A, if too many servers react incorrectly to NS requests); this
514 is the best approach to preserve privacy. But this erases
515 information about the relative use of the various QTYPEs, which may
516 be interesting for researchers (for instance, if they try to follow
517 IPv6 deployment by counting the percentage of AAAA vs. A queries). A
518 variant of QNAME minimisation would be to keep the original QTYPE.
519
520 Another useful optimisation may be, in the spirit of the HAMMER idea
521 [HAMMER], to probe in advance for the introduction of zone cuts where
522 none previously existed (i.e., confirm their continued absence, or
523 discover them).
524
525 To address the "number of queries" issue described in Section 6, a
526 possible solution is to always use the traditional algorithm when the
527 cache is cold and then to move to QNAME minimisation (precisely
528 defining what is "hot" or "cold" is left to the implementer). This
529 will decrease the privacy but will guarantee no degradation of
530 performance.
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Bortzmeyer Experimental [Page 10]
548 RFC 7816 QNAME Minimisation March 2016
549
550
551 Acknowledgments
552
553 Thanks to Olaf Kolkman for the original idea during a KLM flight from
554 Amsterdam to Vancouver, although the concept is probably much older
555 (e.g., <https://lists.dns-oarc.net/pipermail/dns-operations/
556 2010-February/005003.html>). Thanks to Shumon Huque and Marek
557 Vavrusa for implementation and testing. Thanks to Mark Andrews and
558 Francis Dupont for the interesting discussions. Thanks to Brian
559 Dickson, Warren Kumari, Evan Hunt, and David Conrad for remarks and
560 suggestions. Thanks to Mohsen Souissi for proofreading. Thanks to
561 Tony Finch for the zone cut algorithm in Appendix A and for
562 discussion of the algorithm. Thanks to Paul Vixie for pointing out
563 that there are practical advantages (besides privacy) to QNAME
564 minimisation. Thanks to Phillip Hallam-Baker for the fallback on
565 A queries, to deal with broken servers. Thanks to Robert Edmonds for
566 an interesting anti-pattern.
567
568 Author's Address
569
570 Stephane Bortzmeyer
571 AFNIC
572 1, rue Stephenson
573 Montigny-le-Bretonneux 78180
574 France
575
576 Phone: +33 1 39 30 83 46
577 Email: bortzmeyer+ietf@nic.fr
578 URI: http://www.afnic.fr/
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602 Bortzmeyer Experimental [Page 11]
603
QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example. Without QNAME minimisation, it would send these .example name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa.
QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example.com. Without QNAME minimisation, it would send these .example.com name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa.