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