-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-dnsop-qdcount-is-one.txt
392 lines (246 loc) · 14.2 KB
/
draft-ietf-dnsop-qdcount-is-one.txt
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
DNSOP Working Group R. Bellis
Internet-Draft ISC
Updates: 1035 (if approved) J. Abley
Intended status: Standards Track Cloudflare
Expires: 22 December 2024 20 June 2024
In the DNS, QDCOUNT is (usually) One
draft-ietf-dnsop-qdcount-is-one-04
Abstract
This document updates RFC 1035 by constraining the allowed value of
the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a
maximum of one, and specifies the required behaviour when values that
are not allowed are encountered.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 December 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Bellis & Abley Expires 22 December 2024 [Page 1]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology used in this document . . . . . . . . . . . . . . 3
3. QDCOUNT is (usually) One . . . . . . . . . . . . . . . . . . 3
4. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 4
Appendix A. Guidance for the use of QDCOUNT in the DNS
Specification . . . . . . . . . . . . . . . . . . . . . . 5
A.1. OPCODE = 0 (QUERY) and 1 (IQUERY) . . . . . . . . . . . . 5
A.2. OPCODE = 4 (NOTIFY) . . . . . . . . . . . . . . . . . . . 6
A.3. OPCODE = 5 (UPDATE) . . . . . . . . . . . . . . . . . . . 6
A.4. OPCODE = 6 (DNS Stateful Operations, DSO) . . . . . . . . 6
A.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The DNS protocol [RFC1034][RFC1035] includes a parameter QDCOUNT in
the DNS message header, whose value is specified to mean the number
of questions in the Question Section of a DNS message.
In a general sense it seems perfectly plausible for the QDCOUNT
parameter, an unsigned 16-bit value, to take a considerable range of
values. However, in the specific case of messages that encode DNS
queries and responses (messages with OPCODE = 0) there are other
limitations inherent in the protocol that constrain values of QDCOUNT
to be either 0 or 1. In particular, several parameters specified for
DNS response messages such as AA and RCODE have no defined meaning
when the message contains multiple queries, since there is no way to
signal which question those parameters relate to.
In this document we briefly survey the existing written DNS
specification; we provide a description of the semantic and practical
requirements for DNS queries that naturally constrain the allowable
values of QDCOUNT; and we update the DNS base specification to
clarify the allowable values of the QDCODE parameter in the specific
case of DNS messages with OPCODE = 0.
Bellis & Abley Expires 22 December 2024 [Page 2]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
2. Terminology used in this document
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. QDCOUNT is (usually) One
A brief summary of the guidance provided in the existing DNS
specification ([RFC1035] and many other documents) for the use of
QDCOUNT can be found in Appendix A. While the specification is clear
in many cases, in the specific case of OPCODE = 0 there is some
ambiguity which this document aims to eliminate.
4. Updates to RFC 1035
A DNS message with OPCODE = 0 MUST NOT include a QDCOUNT parameter
whose value is greater than 1. It follows that the Question
Section of a DNS message with OPCODE = 0 MUST NOT contain more than
one question.
A DNS message with OPCODE = 0 and QDCOUNT > 1 MUST be treated as an
incorrectly-formatted message. The value of the RCODE parameter in
the response message MUST be set to 1 (FORMERR).
Middleboxes (e.g. firewalls) that process DNS messages in order to
eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and
QDCOUNT > 1 as malformed traffic and return a FORMERR response as
described above. Such firewalls MUST NOT treat messages with OPCODE
= 0 and QDCOUNT = 0 as malformed. See Section 4 of [RFC8906] for
further guidance.
5. Security Considerations
This document clarifies the DNS specification and aims to improve
interoperability between different DNS implementations. In general,
the elimination of ambiguity seems well-aligned with security
hygiene.
6. IANA Considerations
This document has no IANA actions.
Bellis & Abley Expires 22 December 2024 [Page 3]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
7. Acknowledgements
The clarifications in this document were prompted by questions posed
by Ted Lemon, which reminded the authors of earlier, similar
questions and motivated them to pick up their pens. Ondrej Sury,
Warren Kumari, Peter Thomassen, Mark Andrews, Lars-Johan Liman, Jim
Reid and Niall O'Reilly provided useful feedback.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
DOI 10.17487/RFC3425, November 2002,
<https://www.rfc-editor.org/info/rfc3425>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
Bellis & Abley Expires 22 December 2024 [Page 4]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>.
[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem
in DNS Servers: Failure to Communicate", BCP 231,
RFC 8906, DOI 10.17487/RFC8906, September 2020,
<https://www.rfc-editor.org/info/rfc8906>.
Appendix A. Guidance for the use of QDCOUNT in the DNS Specification
The DNS Specification provides some guidance about the values of
QDCOUNT that are appropriate in various situations. A brief summary
of this guidance is collated below.
A.1. OPCODE = 0 (QUERY) and 1 (IQUERY)
[RFC1035] significantly predates the use of the normative
requirements keywords specified in BCP 14 [RFC2119] [RFC8174], and
parts of it are consequently somewhat open to interpretation.
Section 4.1.2 ("Question section format") has this to say about
QDCOUNT:
The section contains QDCOUNT (usually 1) entries
The only documented exceptions within [RFC1035] relate to the IQuery
Opcode, where the request has "an empty question section" (QDCOUNT =
0), and the response has "zero, one, or multiple domain names for the
specified resource as QNAMEs in the question section". The IQuery
OpCode was made obsolete in [RFC3425].
In the absence of clearly expressed normative requirements, we rely
on other text in [RFC1035] that makes use of the definite article or
other text that implies a singular question and, by implication,
QDCOUNT = 1.
For example, Section 4.1:
the question for the name server
and:
Bellis & Abley Expires 22 December 2024 [Page 5]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
The question section contains fields that describe a question to a
name server
and in Section 4.1.1. ("Header section format"):
AA Authoritative Answer - this bit is valid in responses, and
specifies that the responding name server is an authority for the
domain name in question section.
DNS Cookies [RFC7873] in Section 5.4 allow a client to receive a
valid Server Cookie without sending a specific question by sending a
request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting
response also containing no question.
DNS Zone Transfer Protocol (AXFR) [RFC5936] in Section 2.2 allows an
authoritative server optionally to send a response message (QR = 1)
to a standard AXFR query (OPCODE = 0, QTYPE=252) with QDCOUNT = 0 in
the second or subsequent message of a multi-message response.
A.2. OPCODE = 4 (NOTIFY)
DNS Notify [RFC1996] also lacks a clearly defined range of values for
QDCOUNT. Section 3.7 says:
A NOTIFY request has QDCOUNT > 0
but all other text in the RFC talks about the <QNAME, QCLASS, QTYPE>
tuple in the singular.
A.3. OPCODE = 5 (UPDATE)
DNS Update [RFC2136] renames the QDCOUNT field to ZOCOUNT, but the
value is constrained to be one by Section 2.3 ("Zone Section"):
All records to be updated must be in the same zone, and therefore
the Zone Section is allowed to contain exactly one record.
A.4. OPCODE = 6 (DNS Stateful Operations, DSO)
DNS Stateful Operations [RFC8490] (DSO - OpCode 6) attempts to
preserve compatibility with the standard DNS 12 octet header, and
does so by requiring that all four of the section count values be set
to zero.
Bellis & Abley Expires 22 December 2024 [Page 6]
Internet-Draft In the DNS, QDCOUNT is (usually) One June 2024
A.5. Conclusion
There is no text in [RFC1035] that describes how other parameters in
the DNS message such as AA, RCODE should be interpreted in the case
where a message includes more than one question. An originator of a
query with QDCOUNT > 1 can have no expectations of how it will be
processed, and the receiver of a response with QDCOUNT > 1 has no
guidance for how it should be interpreted.
The allowable values of QDCOUNT seem to be clearly specified for
OPCODE = 4 (NOTIFY), OPCODE = 5 (UPDATE) and OPCODE = 6 (DNS Stateful
Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2
(STATUS) is not specified. OPCODE = 3 is reserved.
However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are
specified in [RFC1035] without the clarity of normative language, and
this looseness of language results in some ambiguity.
Authors' Addresses
Ray Bellis
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America
Phone: +1 650 423 1300
Email: [email protected]
Joe Abley
Cloudflare
Amsterdam
Netherlands
Phone: +31 6 45 56 36 34
Email: [email protected]
Bellis & Abley Expires 22 December 2024 [Page 7]