1 Internet Engineering Task Force (IETF) J. Abley
2 Request for Comments: 8482 Afilias
3 Updates: 1034, 1035 O. Gudmundsson
4 Category: Standards Track M. Majkowski
5 ISSN: 2070-1721 Cloudflare Inc.
6 E. Hunt
7 ISC
8 January 2019
9
10
11 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
12
13 Abstract
14
15 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
16 The operator of an authoritative DNS server might choose not to
17 respond to such queries for reasons of local policy, motivated by
18 security, performance, or other reasons.
19
20 The DNS specification does not include specific guidance for the
21 behavior of DNS servers or clients in this situation. This document
22 aims to provide such guidance.
23
24 This document updates RFCs 1034 and 1035.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 7841.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 https://www.rfc-editor.org/info/rfc8482.
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Abley, et al. Standards Track [Page 1]
53 RFC 8482 Minimal Responses for ANY Queries January 2019
54
55
56 Copyright Notice
57
58 Copyright (c) 2019 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction ....................................................3
74 1.1. Terminology ................................................3
75 2. Motivations for Use of ANY Queries ..............................3
76 3. General Approach ................................................4
77 4. Behavior of DNS Responders ......................................5
78 4.1. Answer with a Subset of Available RRsets ...................5
79 4.2. Answer with a Synthesized HINFO RRset ......................5
80 4.3. Answer with Best Guess as to Intention .....................6
81 4.4. Transport Considerations ...................................6
82 5. Behavior of DNS Initiators ......................................7
83 6. HINFO Considerations ............................................7
84 7. Updates to RFCs 1034 and 1035 ...................................7
85 8. Implementation Experience .......................................8
86 9. Security Considerations .........................................8
87 10. IANA Considerations ............................................9
88 11. References .....................................................9
89 11.1. Normative References ......................................9
90 11.2. Informative References ....................................9
91 Acknowledgements ..................................................10
92 Authors' Addresses ................................................10
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Abley, et al. Standards Track [Page 2]
108 RFC 8482 Minimal Responses for ANY Queries January 2019
109
110
111 1. Introduction
112
113 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
114 The operator of an authoritative DNS server might choose not to
115 respond to such queries for reasons of local policy, motivated by
116 security, performance, or other reasons.
117
118 The DNS specification [RFC1034] [RFC1035] does not include specific
119 guidance for the behavior of DNS servers or clients in this
120 situation. This document aims to provide such guidance.
121
122 1.1. Terminology
123
124 This document uses terminology specific to the Domain Name System
125 (DNS), descriptions of which can be found in [RFC8499].
126
127 [RFC1035] defined type 255 to be "*". However, DNS implementations
128 commonly use the keyword "ANY" to refer to that type code; this
129 document follows that common usage.
130
131 In this document, "ANY query" refers to a DNS meta-query with
132 QTYPE=ANY. An "ANY response" is a response to such a query.
133
134 In this document, "conventional ANY response" means an ANY response
135 that is constructed in accordance with the algorithm documented in
136 Section 4.3.2 of [RFC1034] and specifically without implementing any
137 of the mechanisms described in this document.
138
139 In an exchange of DNS messages between two hosts, this document
140 refers to the host sending a DNS request as the "initiator" and the
141 host sending a DNS response as the "responder".
142
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
145 "OPTIONAL" in this document are to be interpreted as described in
146 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
147 capitals, as shown here.
148
149 2. Motivations for Use of ANY Queries
150
151 ANY queries are legitimately used for debugging and checking the
152 state of a DNS server for a particular name.
153
154 ANY queries are sometimes used as an attempt to reduce the number of
155 queries needed to get information, e.g., to obtain MX, A, and AAAA
156 resource record sets (RRsets) for a mail domain in a single query.
157 However, there is no documented guidance available for this use case,
158 and some implementations have been observed not to function as their
159
160
161
162 Abley, et al. Standards Track [Page 3]
163 RFC 8482 Minimal Responses for ANY Queries January 2019
164
165
166 developers expected. If implementers assume that an ANY query will
167 ultimately be received by an authoritative server and will fetch all
168 existing RRsets, they should include a fallback mechanism to use when
169 that does not happen.
170
171 ANY queries are frequently used to exploit the amplification
172 potential of DNS servers and resolvers using spoofed source addresses
173 and UDP transport (see [RFC5358]). Having the ability to return
174 small responses to such queries makes DNS servers less attractive
175 amplifiers.
176
177 ANY queries are sometimes used to help mine authoritative-only DNS
178 servers for zone data, since they are expected to return all RRsets
179 for a particular query name. If DNS operators prefer to reduce the
180 potential for information leaks, they might choose not to send large
181 ANY responses.
182
183 Some authoritative-only DNS server implementations require additional
184 processing in order to send a conventional ANY response; avoiding
185 that processing expense might be desirable.
186
187 3. General Approach
188
189 This proposal provides a mechanism for an authoritative DNS server to
190 signal that conventional ANY queries are not supported for a
191 particular QNAME. It does so in a way that is both compatible with
192 and triggers desirable behavior by unmodified clients (e.g., DNS
193 resolvers).
194
195 Alternative proposals for dealing with ANY queries have been
196 discussed. One approach proposes using a new RCODE to signal that an
197 authoritative server did not answer ANY queries in the standard way.
198 This approach was found to have an undesirable effect on both
199 resolvers and authoritative-only servers; resolvers receiving an
200 unknown RCODE would resend the same query to all available
201 authoritative servers rather than suppress future ANY queries for the
202 same QNAME.
203
204 The proposal described in this document avoids that outcome by
205 returning a non-empty RRset in the ANY response, which provides
206 resolvers with something to cache and effectively suppresses repeat
207 queries to the same or different authoritative DNS servers.
208
209
210
211
212
213
214
215
216
217 Abley, et al. Standards Track [Page 4]
218 RFC 8482 Minimal Responses for ANY Queries January 2019
219
220
221 4. Behavior of DNS Responders
222
223 Below are the three different modes of behavior by DNS responders
224 when processing queries with QNAMEs that exist, QCLASS=IN, and
225 QTYPE=ANY. Operators and implementers are free to choose whichever
226 mechanism best suits their environment.
227
228 1. A DNS responder can choose to select one or a larger subset of
229 the available RRsets at the QNAME.
230
231 2. A DNS responder can return a synthesized HINFO resource record.
232 See Section 6 for discussion of the use of HINFO.
233
234 3. A resolver can try to give out the most likely records the
235 requester wants. This is not always possible, and the result
236 might well be a large response.
237
238 Except as described below in this section, the DNS responder MUST
239 follow the standard algorithms when constructing a response.
240
241 4.1. Answer with a Subset of Available RRsets
242
243 A DNS responder that receives an ANY query MAY decline to provide a
244 conventional ANY response or MAY instead send a response with a
245 single RRset (or a larger subset of available RRsets) in the answer
246 section.
247
248 The RRsets returned in the answer section of the response MAY consist
249 of a single RRset owned by the name specified in the QNAME. Where
250 multiple RRsets exist, the responder SHOULD choose a small subset of
251 those available to reduce the amplification potential of the
252 response.
253
254 If the zone is signed, appropriate RRSIG records MUST be included in
255 the answer.
256
257 Note that this mechanism does not provide any signaling to indicate
258 to a client that an incomplete subset of the available RRsets has
259 been returned.
260
261 4.2. Answer with a Synthesized HINFO RRset
262
263 If there is no CNAME present at the owner name matching the QNAME,
264 the resource record returned in the response MAY instead be
265 synthesized. In this case, a single HINFO resource record SHOULD be
266 returned. The CPU field of the HINFO RDATA SHOULD be set to
267 "RFC8482". The OS field of the HINFO RDATA SHOULD be set to the null
268 string to minimize the size of the response.
269
270
271
272 Abley, et al. Standards Track [Page 5]
273 RFC 8482 Minimal Responses for ANY Queries January 2019
274
275
276 The TTL encoded for the synthesized HINFO resource record SHOULD be
277 chosen by the operator of the DNS responder to be large enough to
278 suppress frequent subsequent ANY queries from the same initiator with
279 the same QNAME, understanding that a TTL that is too long might make
280 policy changes relating to ANY queries difficult to change in the
281 future. The specific value used SHOULD be configurable by the
282 operator of the nameserver according to local policy, based on the
283 familiar considerations involved in choosing a TTL value for any
284 resource record in any zone.
285
286 If the DNS query includes DO=1 and the QNAME corresponds to a zone
287 that is known by the responder to be signed, a valid RRSIG for the
288 RRsets in the answer (or authority if answer is empty) section MUST
289 be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
290
291 A system that receives an HINFO response SHOULD NOT infer that the
292 response was generated according to this specification and apply any
293 special processing of the response because, in general, it is not
294 possible to tell with certainty whether the HINFO RRset received was
295 synthesized. In particular, systems SHOULD NOT rely upon the HINFO
296 RDATA described in this section to distinguish between synthesized
297 and non-synthesized HINFO RRsets.
298
299 4.3. Answer with Best Guess as to Intention
300
301 In some cases, it is possible to guess what the initiator wants in
302 the answer (but not always). Some implementations have implemented
303 the spirit of this document by returning all RRsets of RRTYPE CNAME,
304 MX, A, and AAAA that are present at the owner name while suppressing
305 others. This heuristic seems to work well in practice; it satisfies
306 the needs of some applications whilst suppressing other RRsets such
307 as TXT and DNSKEY that can often contribute to large responses.
308 Whilst some applications may be satisfied by this behavior, the
309 resulting responses in the general case are larger than in the
310 approaches described in Sections 4.1 and 4.2.
311
312 As before, if the zone is signed and the DO bit is set on the
313 corresponding query, an RRSIG RRset MUST be included in the response.
314
315 4.4. Transport Considerations
316
317 A DNS responder MAY behave differently when processing ANY queries
318 received over different transports, e.g., by providing a conventional
319 ANY response over TCP whilst using one of the other mechanisms
320 specified in this document in the case where a query was received
321 using UDP.
322
323
324
325
326
327 Abley, et al. Standards Track [Page 6]
328 RFC 8482 Minimal Responses for ANY Queries January 2019
329
330
331 Implementers MAY provide configuration options to allow operators to
332 specify different behavior over different transports.
333
334 5. Behavior of DNS Initiators
335
336 A DNS initiator that sends a query with QTYPE=ANY and receives a
337 response containing an HINFO resource record or a single RRset, as
338 described in Section 4, MAY cache the response in the normal way.
339 Such cached resource records SHOULD be retained in the cache
340 following normal caching semantics, as with any other response
341 received from a DNS responder.
342
343 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
344 the local cache contains a matching HINFO resource record with the
345 CPU field of the HINFO RDATA, as described in Section 4. A DNS
346 initiator MAY instead respond to such queries with the contents of
347 the local cache in the usual way.
348
349 6. HINFO Considerations
350
351 It is possible that the synthesized HINFO RRset in an ANY response,
352 once cached by the initiator, might suppress subsequent queries from
353 the same initiator with QTYPE=HINFO. Thus, the use of HINFO in this
354 proposal would effectively mask the HINFO RRset present in the zone.
355
356 Operators of authoritative servers who serve zones that rely upon
357 conventional use of the HINFO RRTYPE SHOULD sensibly choose the
358 "single RRset" method described in this document or select another
359 type.
360
361 The HINFO RRTYPE is believed to be rarely used in the DNS at the time
362 of writing, based on observations made in passive DNS and at
363 recursive and authoritative DNS servers.
364
365 7. Updates to RFCs 1034 and 1035
366
367 This document extends the specification for processing ANY queries
368 described in Section 4.3.2 of [RFC1034].
369
370 It is important to note that returning a subset of available RRsets
371 when processing an ANY query is legitimate and consistent with
372 [RFC1035]; it can be argued that ANY does not always mean ALL, as
373 used in Section 3.2.3 of [RFC1035]. The main difference here is that
374 the TC bit SHOULD NOT be set in the response, thus indicating that
375 this is not a complete answer.
376
377
378
379
380
381
382 Abley, et al. Standards Track [Page 7]
383 RFC 8482 Minimal Responses for ANY Queries January 2019
384
385
386 This document describes optional behavior for both DNS initiators and
387 responders; implementation of the guidance provided by this document
388 is OPTIONAL.
389
390 RRSIG queries (i.e., queries with QTYPE=RRSIG) are similar to ANY
391 queries in the sense that they have the potential to generate large
392 responses as well as extra work for the responders that process them,
393 e.g., in the case where signatures are generated on the fly. RRSIG
394 RRsets are not usually obtained using such explicit queries but are
395 rather included in the responses for other RRsets that the RRSIGs
396 cover. This document does not specify appropriate behavior for RRSIG
397 queries; however, future such advice might well benefit from
398 consistency with and experience with the approaches for ANY queries
399 described here.
400
401 8. Implementation Experience
402
403 In October 2015, the Cloudflare authoritative nameserver
404 implementation implemented the HINFO response. A few minor problems
405 were reported and have since been resolved.
406
407 An implementation of the subset-mode response to ANY queries was
408 implemented in NSD 4.1 in 2016.
409
410 An implementation of a single RRset response to an ANY query was made
411 for BIND9 by Tony Finch, and that functionality was subsequently made
412 available in production releases starting in BIND 9.11.
413
414 9. Security Considerations
415
416 Queries with QTYPE=ANY are frequently observed as part of reflection
417 attacks, since a relatively small query can be used to elicit a large
418 response. This is a desirable characteristic if the goal is to
419 maximize the amplification potential of a DNS server as part of a
420 volumetric attack. The ability of a DNS operator to suppress such
421 responses on a particular server makes that server a less useful
422 amplifier.
423
424 The optional behavior described in this document to reduce the size
425 of responses to queries with QTYPE=ANY is compatible with the use of
426 DNSSEC by both initiator and responder.
427
428
429
430
431
432
433
434
435
436
437 Abley, et al. Standards Track [Page 8]
438 RFC 8482 Minimal Responses for ANY Queries January 2019
439
440
441 10. IANA Considerations
442
443 IANA has updated the following entry in the "Resource Record (RR)
444 TYPEs" registry [RR_TYPES]:
445
446 +------+-------+-------------------------------+--------------------+
447 | TYPE | Value | Meaning | Reference |
448 +------+-------+-------------------------------+--------------------+
449 | * | 255 | A request for some or all | [RFC1035][RFC6895] |
450 | | | records the server has | [RFC8482] |
451 | | | available | |
452 +------+-------+-------------------------------+--------------------+
453
454 11. References
455
456 11.1. Normative References
457
458 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
459 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
460 <https://www.rfc-editor.org/info/rfc1034>.
461
462 [RFC1035] Mockapetris, P., "Domain names - implementation and
463 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
464 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
465
466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
467 Requirement Levels", BCP 14, RFC 2119,
468 DOI 10.17487/RFC2119, March 1997,
469 <https://www.rfc-editor.org/info/rfc2119>.
470
471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
473 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
474
475 11.2. Informative References
476
477 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
478 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
479 DOI 10.17487/RFC5358, October 2008,
480 <https://www.rfc-editor.org/info/rfc5358>.
481
482 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
483 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
484 April 2013, <https://www.rfc-editor.org/info/rfc6895>.
485
486 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
487 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
488 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
489
490
491
492 Abley, et al. Standards Track [Page 9]
493 RFC 8482 Minimal Responses for ANY Queries January 2019
494
495
496 [RR_TYPES] IANA, "Domain Name System (DNS) Parameters",
497 <https://www.iana.org/assignments/dns-parameters>.
498
499 Acknowledgements
500
501 David Lawrence provided valuable observations and concrete
502 suggestions. Jeremy Laidman helped make the document better. Tony
503 Finch realized that this document was valuable and implemented it
504 while under attack. Richard Gibson identified areas where more
505 detail and accuracy were useful. A large number of other people also
506 provided comments and suggestions; we thank them all for the
507 feedback.
508
509 Authors' Addresses
510
511 Joe Abley
512 Afilias
513 300-184 York Street
514 London, ON N6A 1B5
515 Canada
516
517 Phone: +1 519 670 9327
518 Email: jabley@afilias.info
519
520
521 Olafur Gudmundsson
522 Cloudflare Inc.
523
524 Email: olafur+ietf@cloudflare.com
525
526
527 Marek Majkowski
528 Cloudflare Inc.
529
530 Email: marek@cloudflare.com
531
532
533 Evan Hunt
534 ISC
535 950 Charter St
536 Redwood City, CA 94063
537 United States of America
538
539 Email: each@isc.org
540
541
542
543
544
545
546
547 Abley, et al. Standards Track [Page 10]
548
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.