7Internet Engineering Task Force (IETF) J. Abley
8Request for Comments: 8482 Afilias
9Updates: 1034, 1035 O. Gudmundsson
10Category: Standards Track M. Majkowski
11ISSN: 2070-1721 Cloudflare Inc.
17 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
21 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
22 The operator of an authoritative DNS server might choose not to
23 respond to such queries for reasons of local policy, motivated by
24 security, performance, or other reasons.
26 The DNS specification does not include specific guidance for the
27 behavior of DNS servers or clients in this situation. This document
28 aims to provide such guidance.
30 This document updates RFCs 1034 and 1035.
34 This is an Internet Standards Track document.
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Further information on
40 Internet Standards is available in Section 2 of RFC 7841.
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 https://www.rfc-editor.org/info/rfc8482.
58Abley, et al. Standards Track [Page 1]
60RFC 8482 Minimal Responses for ANY Queries January 2019
65 Copyright (c) 2019 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (https://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction ....................................................3
81 1.1. Terminology ................................................3
82 2. Motivations for Use of ANY Queries ..............................3
83 3. General Approach ................................................4
84 4. Behavior of DNS Responders ......................................5
85 4.1. Answer with a Subset of Available RRsets ...................5
86 4.2. Answer with a Synthesized HINFO RRset ......................5
87 4.3. Answer with Best Guess as to Intention .....................6
88 4.4. Transport Considerations ...................................6
89 5. Behavior of DNS Initiators ......................................7
90 6. HINFO Considerations ............................................7
91 7. Updates to RFCs 1034 and 1035 ...................................7
92 8. Implementation Experience .......................................8
93 9. Security Considerations .........................................8
94 10. IANA Considerations ............................................9
95 11. References .....................................................9
96 11.1. Normative References ......................................9
97 11.2. Informative References ....................................9
98 Acknowledgements ..................................................10
99 Authors' Addresses ................................................10
114Abley, et al. Standards Track [Page 2]
116RFC 8482 Minimal Responses for ANY Queries January 2019
121 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
122 The operator of an authoritative DNS server might choose not to
123 respond to such queries for reasons of local policy, motivated by
124 security, performance, or other reasons.
126 The DNS specification [RFC1034] [RFC1035] does not include specific
127 guidance for the behavior of DNS servers or clients in this
128 situation. This document aims to provide such guidance.
132 This document uses terminology specific to the Domain Name System
133 (DNS), descriptions of which can be found in [RFC8499].
135 [RFC1035] defined type 255 to be "*". However, DNS implementations
136 commonly use the keyword "ANY" to refer to that type code; this
137 document follows that common usage.
139 In this document, "ANY query" refers to a DNS meta-query with
140 QTYPE=ANY. An "ANY response" is a response to such a query.
142 In this document, "conventional ANY response" means an ANY response
143 that is constructed in accordance with the algorithm documented in
144 Section 4.3.2 of [RFC1034] and specifically without implementing any
145 of the mechanisms described in this document.
147 In an exchange of DNS messages between two hosts, this document
148 refers to the host sending a DNS request as the "initiator" and the
149 host sending a DNS response as the "responder".
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
153 "OPTIONAL" in this document are to be interpreted as described in
154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
155 capitals, as shown here.
1572. Motivations for Use of ANY Queries
159 ANY queries are legitimately used for debugging and checking the
160 state of a DNS server for a particular name.
162 ANY queries are sometimes used as an attempt to reduce the number of
163 queries needed to get information, e.g., to obtain MX, A, and AAAA
164 resource record sets (RRsets) for a mail domain in a single query.
165 However, there is no documented guidance available for this use case,
166 and some implementations have been observed not to function as their
170Abley, et al. Standards Track [Page 3]
172RFC 8482 Minimal Responses for ANY Queries January 2019
175 developers expected. If implementers assume that an ANY query will
176 ultimately be received by an authoritative server and will fetch all
177 existing RRsets, they should include a fallback mechanism to use when
178 that does not happen.
180 ANY queries are frequently used to exploit the amplification
181 potential of DNS servers and resolvers using spoofed source addresses
182 and UDP transport (see [RFC5358]). Having the ability to return
183 small responses to such queries makes DNS servers less attractive
186 ANY queries are sometimes used to help mine authoritative-only DNS
187 servers for zone data, since they are expected to return all RRsets
188 for a particular query name. If DNS operators prefer to reduce the
189 potential for information leaks, they might choose not to send large
192 Some authoritative-only DNS server implementations require additional
193 processing in order to send a conventional ANY response; avoiding
194 that processing expense might be desirable.
198 This proposal provides a mechanism for an authoritative DNS server to
199 signal that conventional ANY queries are not supported for a
200 particular QNAME. It does so in a way that is both compatible with
201 and triggers desirable behavior by unmodified clients (e.g., DNS
204 Alternative proposals for dealing with ANY queries have been
205 discussed. One approach proposes using a new RCODE to signal that an
206 authoritative server did not answer ANY queries in the standard way.
207 This approach was found to have an undesirable effect on both
208 resolvers and authoritative-only servers; resolvers receiving an
209 unknown RCODE would resend the same query to all available
210 authoritative servers rather than suppress future ANY queries for the
213 The proposal described in this document avoids that outcome by
214 returning a non-empty RRset in the ANY response, which provides
215 resolvers with something to cache and effectively suppresses repeat
216 queries to the same or different authoritative DNS servers.
226Abley, et al. Standards Track [Page 4]
228RFC 8482 Minimal Responses for ANY Queries January 2019
2314. Behavior of DNS Responders
233 Below are the three different modes of behavior by DNS responders
234 when processing queries with QNAMEs that exist, QCLASS=IN, and
235 QTYPE=ANY. Operators and implementers are free to choose whichever
236 mechanism best suits their environment.
238 1. A DNS responder can choose to select one or a larger subset of
239 the available RRsets at the QNAME.
241 2. A DNS responder can return a synthesized HINFO resource record.
242 See Section 6 for discussion of the use of HINFO.
244 3. A resolver can try to give out the most likely records the
245 requester wants. This is not always possible, and the result
246 might well be a large response.
248 Except as described below in this section, the DNS responder MUST
249 follow the standard algorithms when constructing a response.
2514.1. Answer with a Subset of Available RRsets
253 A DNS responder that receives an ANY query MAY decline to provide a
254 conventional ANY response or MAY instead send a response with a
255 single RRset (or a larger subset of available RRsets) in the answer
258 The RRsets returned in the answer section of the response MAY consist
259 of a single RRset owned by the name specified in the QNAME. Where
260 multiple RRsets exist, the responder SHOULD choose a small subset of
261 those available to reduce the amplification potential of the
264 If the zone is signed, appropriate RRSIG records MUST be included in
267 Note that this mechanism does not provide any signaling to indicate
268 to a client that an incomplete subset of the available RRsets has
2714.2. Answer with a Synthesized HINFO RRset
273 If there is no CNAME present at the owner name matching the QNAME,
274 the resource record returned in the response MAY instead be
275 synthesized. In this case, a single HINFO resource record SHOULD be
276 returned. The CPU field of the HINFO RDATA SHOULD be set to
277 "RFC8482". The OS field of the HINFO RDATA SHOULD be set to the null
278 string to minimize the size of the response.
282Abley, et al. Standards Track [Page 5]
284RFC 8482 Minimal Responses for ANY Queries January 2019
287 The TTL encoded for the synthesized HINFO resource record SHOULD be
288 chosen by the operator of the DNS responder to be large enough to
289 suppress frequent subsequent ANY queries from the same initiator with
290 the same QNAME, understanding that a TTL that is too long might make
291 policy changes relating to ANY queries difficult to change in the
292 future. The specific value used SHOULD be configurable by the
293 operator of the nameserver according to local policy, based on the
294 familiar considerations involved in choosing a TTL value for any
295 resource record in any zone.
297 If the DNS query includes DO=1 and the QNAME corresponds to a zone
298 that is known by the responder to be signed, a valid RRSIG for the
299 RRsets in the answer (or authority if answer is empty) section MUST
300 be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
302 A system that receives an HINFO response SHOULD NOT infer that the
303 response was generated according to this specification and apply any
304 special processing of the response because, in general, it is not
305 possible to tell with certainty whether the HINFO RRset received was
306 synthesized. In particular, systems SHOULD NOT rely upon the HINFO
307 RDATA described in this section to distinguish between synthesized
308 and non-synthesized HINFO RRsets.
3104.3. Answer with Best Guess as to Intention
312 In some cases, it is possible to guess what the initiator wants in
313 the answer (but not always). Some implementations have implemented
314 the spirit of this document by returning all RRsets of RRTYPE CNAME,
315 MX, A, and AAAA that are present at the owner name while suppressing
316 others. This heuristic seems to work well in practice; it satisfies
317 the needs of some applications whilst suppressing other RRsets such
318 as TXT and DNSKEY that can often contribute to large responses.
319 Whilst some applications may be satisfied by this behavior, the
320 resulting responses in the general case are larger than in the
321 approaches described in Sections 4.1 and 4.2.
323 As before, if the zone is signed and the DO bit is set on the
324 corresponding query, an RRSIG RRset MUST be included in the response.
3264.4. Transport Considerations
328 A DNS responder MAY behave differently when processing ANY queries
329 received over different transports, e.g., by providing a conventional
330 ANY response over TCP whilst using one of the other mechanisms
331 specified in this document in the case where a query was received
338Abley, et al. Standards Track [Page 6]
340RFC 8482 Minimal Responses for ANY Queries January 2019
343 Implementers MAY provide configuration options to allow operators to
344 specify different behavior over different transports.
3465. Behavior of DNS Initiators
348 A DNS initiator that sends a query with QTYPE=ANY and receives a
349 response containing an HINFO resource record or a single RRset, as
350 described in Section 4, MAY cache the response in the normal way.
351 Such cached resource records SHOULD be retained in the cache
352 following normal caching semantics, as with any other response
353 received from a DNS responder.
355 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
356 the local cache contains a matching HINFO resource record with the
357 CPU field of the HINFO RDATA, as described in Section 4. A DNS
358 initiator MAY instead respond to such queries with the contents of
359 the local cache in the usual way.
3616. HINFO Considerations
363 It is possible that the synthesized HINFO RRset in an ANY response,
364 once cached by the initiator, might suppress subsequent queries from
365 the same initiator with QTYPE=HINFO. Thus, the use of HINFO in this
366 proposal would effectively mask the HINFO RRset present in the zone.
368 Operators of authoritative servers who serve zones that rely upon
369 conventional use of the HINFO RRTYPE SHOULD sensibly choose the
370 "single RRset" method described in this document or select another
373 The HINFO RRTYPE is believed to be rarely used in the DNS at the time
374 of writing, based on observations made in passive DNS and at
375 recursive and authoritative DNS servers.
3777. Updates to RFCs 1034 and 1035
379 This document extends the specification for processing ANY queries
380 described in Section 4.3.2 of [RFC1034].
382 It is important to note that returning a subset of available RRsets
383 when processing an ANY query is legitimate and consistent with
384 [RFC1035]; it can be argued that ANY does not always mean ALL, as
385 used in Section 3.2.3 of [RFC1035]. The main difference here is that
386 the TC bit SHOULD NOT be set in the response, thus indicating that
387 this is not a complete answer.
394Abley, et al. Standards Track [Page 7]
396RFC 8482 Minimal Responses for ANY Queries January 2019
399 This document describes optional behavior for both DNS initiators and
400 responders; implementation of the guidance provided by this document
403 RRSIG queries (i.e., queries with QTYPE=RRSIG) are similar to ANY
404 queries in the sense that they have the potential to generate large
405 responses as well as extra work for the responders that process them,
406 e.g., in the case where signatures are generated on the fly. RRSIG
407 RRsets are not usually obtained using such explicit queries but are
408 rather included in the responses for other RRsets that the RRSIGs
409 cover. This document does not specify appropriate behavior for RRSIG
410 queries; however, future such advice might well benefit from
411 consistency with and experience with the approaches for ANY queries
4148. Implementation Experience
416 In October 2015, the Cloudflare authoritative nameserver
417 implementation implemented the HINFO response. A few minor problems
418 were reported and have since been resolved.
420 An implementation of the subset-mode response to ANY queries was
421 implemented in NSD 4.1 in 2016.
423 An implementation of a single RRset response to an ANY query was made
424 for BIND9 by Tony Finch, and that functionality was subsequently made
425 available in production releases starting in BIND 9.11.
4279. Security Considerations
429 Queries with QTYPE=ANY are frequently observed as part of reflection
430 attacks, since a relatively small query can be used to elicit a large
431 response. This is a desirable characteristic if the goal is to
432 maximize the amplification potential of a DNS server as part of a
433 volumetric attack. The ability of a DNS operator to suppress such
434 responses on a particular server makes that server a less useful
437 The optional behavior described in this document to reduce the size
438 of responses to queries with QTYPE=ANY is compatible with the use of
439 DNSSEC by both initiator and responder.
450Abley, et al. Standards Track [Page 8]
452RFC 8482 Minimal Responses for ANY Queries January 2019
45510. IANA Considerations
457 IANA has updated the following entry in the "Resource Record (RR)
458 TYPEs" registry [RR_TYPES]:
460 +------+-------+-------------------------------+--------------------+
461 | TYPE | Value | Meaning | Reference |
462 +------+-------+-------------------------------+--------------------+
463 | * | 255 | A request for some or all | [RFC1035][RFC6895] |
464 | | | records the server has | [RFC8482] |
466 +------+-------+-------------------------------+--------------------+
47011.1. Normative References
472 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
473 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
474 <https://www.rfc-editor.org/info/rfc1034>.
476 [RFC1035] Mockapetris, P., "Domain names - implementation and
477 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
478 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
481 Requirement Levels", BCP 14, RFC 2119,
482 DOI 10.17487/RFC2119, March 1997,
483 <https://www.rfc-editor.org/info/rfc2119>.
485 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
486 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
487 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
48911.2. Informative References
491 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
492 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
493 DOI 10.17487/RFC5358, October 2008,
494 <https://www.rfc-editor.org/info/rfc5358>.
496 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
497 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
498 April 2013, <https://www.rfc-editor.org/info/rfc6895>.
500 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
501 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
502 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
506Abley, et al. Standards Track [Page 9]
508RFC 8482 Minimal Responses for ANY Queries January 2019
511 [RR_TYPES] IANA, "Domain Name System (DNS) Parameters",
512 <https://www.iana.org/assignments/dns-parameters>.
516 David Lawrence provided valuable observations and concrete
517 suggestions. Jeremy Laidman helped make the document better. Tony
518 Finch realized that this document was valuable and implemented it
519 while under attack. Richard Gibson identified areas where more
520 detail and accuracy were useful. A large number of other people also
521 provided comments and suggestions; we thank them all for the
532 Phone: +1 519 670 9327
533 Email: jabley@afilias.info
539 Email: olafur+ietf@cloudflare.com
545 Email: marek@cloudflare.com
551 Redwood City, CA 94063
552 United States of America
562Abley, et al. Standards Track [Page 10]