Diff: rfc9619.original

	rfc9619.original	rfc9619.txt


	DNSOP Working Group R. Bellis	Internet Engineering Task Force (IETF) R. Bellis
	Internet-Draft ISC	Request for Comments: 9619 ISC
	Updates: 1035 (if approved) J. Abley	Updates: 1035 J. Abley
	Intended status: Standards Track Cloudflare	Category: Standards Track Cloudflare
	Expires: 30 November 2024 29 May 2024	ISSN: 2070-1721 July 2024


	In the DNS, QDCOUNT is (usually) One	In the DNS, QDCOUNT Is (Usually) One
	draft-ietf-dnsop-qdcount-is-one-04

	Abstract	Abstract

	This document updates RFC 1035 by constraining the allowed value of	This document updates RFC 1035 by constraining the allowed value of
	the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a	the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a

	maximum of one, and specifies the required behaviour when values that	maximum of one, and it specifies the required behavior when values
	are not allowed are encountered.	that are not allowed are encountered.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	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	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 30 November 2024.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9619.

	Copyright Notice	Copyright Notice

	Copyright (c) 2024 IETF Trust and the persons identified as the	Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal

	Provisions Relating to IETF Documents (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction
	2. Terminology used in this document . . . . . . . . . . . . . . 3	2. Terminology Used in This Document
	3. QDCOUNT is (usually) One . . . . . . . . . . . . . . . . . . 3	3. QDCOUNT Is (Usually) One
	4. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 3	4. Updates to RFC 1035
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 3	5. Security Considerations
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3	6. IANA Considerations
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4	7. References
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4	7.1. Normative References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 4	7.2. Informative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 4	Appendix A. Guidance for the Use of QDCOUNT in the DNS
	Appendix A. Guidance for the use of QDCOUNT in the DNS	Specification
	Specification . . . . . . . . . . . . . . . . . . . . . . 5	A.1. OPCODE = 0 (QUERY) and 1 (IQUERY)
	A.1. OPCODE = 0 (QUERY) and 1 (IQUERY) . . . . . . . . . . . . 5	A.2. OPCODE = 4 (NOTIFY)
	A.2. OPCODE = 4 (NOTIFY) . . . . . . . . . . . . . . . . . . . 6	A.3. OPCODE = 5 (UPDATE)
	A.3. OPCODE = 5 (UPDATE) . . . . . . . . . . . . . . . . . . . 6	A.4. OPCODE = 6 (DNS Stateful Operations, DSO)
	A.4. OPCODE = 6 (DNS Stateful Operations, DSO) . . . . . . . . 6	A.5. Conclusion
	A.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 7	Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7	Authors' Addresses

	1. Introduction	1. Introduction


	The DNS protocol [RFC1034][RFC1035] includes a parameter QDCOUNT in	The DNS protocol [RFC1034] [RFC1035] includes a parameter QDCOUNT in
	the DNS message header, whose value is specified to mean the number	the DNS message header whose value is specified to mean the number of
	of questions in the Question Section of a DNS message.	questions in the Question section of a DNS message.


	In a general sense it seems perfectly plausible for the QDCOUNT	In a general sense, it seems perfectly plausible for the QDCOUNT
	parameter, an unsigned 16-bit value, to take a considerable range of	parameter, an unsigned 16-bit value, to take a considerable range of
	values. However, in the specific case of messages that encode DNS	values. However, in the specific case of messages that encode DNS

	queries and responses (messages with OPCODE = 0) there are other	queries and responses (messages with OPCODE = 0), there are other
	limitations inherent in the protocol that constrain values of QDCOUNT	limitations inherent in the protocol that constrain values of QDCOUNT
	to be either 0 or 1. In particular, several parameters specified for	to be either 0 or 1. In particular, several parameters specified for
	DNS response messages such as AA and RCODE have no defined meaning	DNS response messages such as AA and RCODE have no defined meaning

	when the message contains multiple queries, since there is no way to	when the message contains multiple queries as there is no way to
	signal which question those parameters relate to.	signal which question those parameters relate to.


	In this document we briefly survey the existing written DNS	In this document, we briefly survey the existing written DNS
	specification; we provide a description of the semantic and practical	specification; provide a description of the semantic and practical
	requirements for DNS queries that naturally constrain the allowable	requirements for DNS queries that naturally constrain the allowable

	values of QDCOUNT; and we update the DNS base specification to	values of QDCOUNT; and update the DNS base specification to clarify
	clarify the allowable values of the QDCODE parameter in the specific	the allowable values of the QDCODE parameter in the specific case of
	case of DNS messages with OPCODE = 0.	DNS messages with OPCODE = 0.


	2. Terminology used in this document	2. Terminology Used in This Document

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

	"OPTIONAL" in this document are to be interpreted as described in BCP	"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.


	3. QDCOUNT is (usually) One	3. QDCOUNT Is (Usually) One

	A brief summary of the guidance provided in the existing DNS	A brief summary of the guidance provided in the existing DNS
	specification ([RFC1035] and many other documents) for the use of	specification ([RFC1035] and many other documents) for the use of
	QDCOUNT can be found in Appendix A. While the specification is clear	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	in many cases, there is some ambiguity in the specific case of OPCODE
	ambiguity which this document aims to eliminate.	= 0, which this document aims to eliminate.

	4. Updates to RFC 1035	4. Updates to RFC 1035

	A DNS message with OPCODE = 0 MUST NOT include a QDCOUNT parameter	A DNS message with OPCODE = 0 MUST NOT include a QDCOUNT parameter

	whose value is greater than 1. It follows that the Question	whose value is greater than 1. It follows that the Question section
	Section of a DNS message with OPCODE = 0 MUST NOT contain more than	of a DNS message with OPCODE = 0 MUST NOT contain more than one
	one question.	question.

	A DNS message with OPCODE = 0 and QDCOUNT > 1 MUST be treated as an	A DNS message with OPCODE = 0 and QDCOUNT > 1 MUST be treated as an

	incorrectly-formatted message. The value of the RCODE parameter in	incorrectly formatted message. The value of the RCODE parameter in
	the response message MUST be set to 1 (FORMERR).	the response message MUST be set to 1 (FORMERR).


	Middleboxes (e.g. firewalls) that process DNS messages in order to	Middleboxes (e.g., firewalls) that process DNS messages in order to
	eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and	eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and
	QDCOUNT > 1 as malformed traffic and return a FORMERR response as	QDCOUNT > 1 as malformed traffic and return a FORMERR response as
	described above. Such firewalls MUST NOT treat messages with OPCODE	described above. Such firewalls MUST NOT treat messages with OPCODE
	= 0 and QDCOUNT = 0 as malformed. See Section 4 of [RFC8906] for	= 0 and QDCOUNT = 0 as malformed. See Section 4 of [RFC8906] for
	further guidance.	further guidance.

	5. Security Considerations	5. Security Considerations


	This document clarifies the DNS specification and aims to improve	This document clarifies the DNS specification [RFC1035] and aims to
	interoperability between different DNS implementations. In general,	improve interoperability between different DNS implementations. In
	the elimination of ambiguity seems well-aligned with security	general, the elimination of ambiguity seems well-aligned with
	hygiene.	security hygiene.

	6. IANA Considerations	6. IANA Considerations

	This document has no IANA actions.	This document has no IANA actions.


	7. Acknowledgements	7. References

	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	7.1. Normative References

	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.	<https://www.rfc-editor.org/info/rfc1034>.

	[RFC1035] Mockapetris, P., "Domain names - implementation and	[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.	November 1987, <https://www.rfc-editor.org/info/rfc1035>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

	skipping to change at page 4, line 38 ¶	skipping to change at line 160 ¶
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,	[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
	DOI 10.17487/RFC3425, November 2002,	DOI 10.17487/RFC3425, November 2002,
	<https://www.rfc-editor.org/info/rfc3425>.	<https://www.rfc-editor.org/info/rfc3425>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.


	8.2. Informative References	7.2. Informative References

	[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone	[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
	Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,	Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
	August 1996, <https://www.rfc-editor.org/info/rfc1996>.	August 1996, <https://www.rfc-editor.org/info/rfc1996>.

	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,	[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",	"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, DOI 10.17487/RFC2136, April 1997,	RFC 2136, DOI 10.17487/RFC2136, April 1997,
	<https://www.rfc-editor.org/info/rfc2136>.	<https://www.rfc-editor.org/info/rfc2136>.


	skipping to change at page 5, line 19 ¶	skipping to change at line 189 ¶
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",	Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	RFC 8490, DOI 10.17487/RFC8490, March 2019,	RFC 8490, DOI 10.17487/RFC8490, March 2019,
	<https://www.rfc-editor.org/info/rfc8490>.	<https://www.rfc-editor.org/info/rfc8490>.

	[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem	[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem
	in DNS Servers: Failure to Communicate", BCP 231,	in DNS Servers: Failure to Communicate", BCP 231,
	RFC 8906, DOI 10.17487/RFC8906, September 2020,	RFC 8906, DOI 10.17487/RFC8906, September 2020,
	<https://www.rfc-editor.org/info/rfc8906>.	<https://www.rfc-editor.org/info/rfc8906>.


	Appendix A. Guidance for the use of QDCOUNT in the DNS Specification	Appendix A. Guidance for the Use of QDCOUNT in the DNS Specification


	The DNS Specification provides some guidance about the values of	The DNS specification [RFC1035] provides some guidance about the
	QDCOUNT that are appropriate in various situations. A brief summary	values of QDCOUNT that are appropriate in various situations. A
	of this guidance is collated below.	brief summary of this guidance is collated below.

	A.1. OPCODE = 0 (QUERY) and 1 (IQUERY)	A.1. OPCODE = 0 (QUERY) and 1 (IQUERY)


	[RFC1035] significantly predates the use of the normative	[RFC1035] significantly predates the use of the normative requirement
	requirements keywords specified in BCP 14 [RFC2119] [RFC8174], and	key words specified in BCP 14 [RFC2119] [RFC8174], and parts of it
	parts of it are consequently somewhat open to interpretation.	are consequently somewhat open to interpretation.


	Section 4.1.2 ("Question section format") has this to say about	Section 4.1.2 ("Question section format") of [RFC1035] states the
	QDCOUNT:	following about QDCOUNT:


	The section contains QDCOUNT (usually 1) entries	"The section contains QDCOUNT (usually 1) entries"

	The only documented exceptions within [RFC1035] relate to the IQuery	The only documented exceptions within [RFC1035] relate to the IQuery

	Opcode, where the request has "an empty question section" (QDCOUNT =	OpCode, where the request has "an empty question section" (QDCOUNT =
	0), and the response has "zero, one, or multiple domain names for the	0), and the response has "zero, one, or multiple domain names for the
	specified resource as QNAMEs in the question section". The IQuery	specified resource as QNAMEs in the question section". The IQuery

	OpCode was made obsolete in [RFC3425].	OpCode was obsoleted by [RFC3425].

	In the absence of clearly expressed normative requirements, we rely	In the absence of clearly expressed normative requirements, we rely
	on other text in [RFC1035] that makes use of the definite article or	on other text in [RFC1035] that makes use of the definite article or

	other text that implies a singular question and, by implication,	that implies a singular question and, by implication, QDCOUNT = 1.
	QDCOUNT = 1.


	For example, Section 4.1:	For example, Section 4.1 of [RFC1035] states the following:


	the question for the name server	"the question for the name server"


	and:	and


	The question section contains fields that describe a question to a	"The question section contains fields that describe a question to
	name server	a name server."


	and in Section 4.1.1. ("Header section format"):	And per Section 4.1.1 ("Header section format") of [RFC1035]:


	AA Authoritative Answer - this bit is valid in responses, and	"AA: Authoritative Answer - this bit is valid in responses, and
	specifies that the responding name server is an authority for the	specifies that the responding name server is an authority for the

	domain name in question section.	domain name in question section."


	DNS Cookies [RFC7873] in Section 5.4 allow a client to receive a	DNS Cookies (Section 5.4 of [RFC7873]) allow a client to receive a
	valid Server Cookie without sending a specific question by sending a	valid Server Cookie without sending a specific question by sending a
	request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting	request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting
	response also containing no question.	response also containing no question.


	DNS Zone Transfer Protocol (AXFR) [RFC5936] in Section 2.2 allows an	The DNS Zone Transfer Protocol (Section 2.2 of [RFC5936]) allows an
	authoritative server optionally to send a response message (QR = 1)	authoritative server to optionally send a response message (QR = 1)
	to a standard AXFR query (OPCODE = 0, QTYPE=252) with QDCOUNT = 0 in	to a standard Authoritative Transfer (AXFR) query (OPCODE = 0,
	the second or subsequent message of a multi-message response.	QTYPE=252) with QDCOUNT = 0 in the second or subsequent message of a
		multi-message response.

	A.2. OPCODE = 4 (NOTIFY)	A.2. OPCODE = 4 (NOTIFY)

	DNS Notify [RFC1996] also lacks a clearly defined range of values for	DNS Notify [RFC1996] also lacks a clearly defined range of values for

	QDCOUNT. Section 3.7 says:	QDCOUNT. Section 3.7 states that:


	A NOTIFY request has QDCOUNT > 0	"A NOTIFY request has QDCOUNT>0"


	but all other text in the RFC talks about the <QNAME, QCLASS, QTYPE>	However, all other text in the RFC discusses the <QNAME, QCLASS,
	tuple in the singular.	QTYPE> tuple in the singular form.

	A.3. OPCODE = 5 (UPDATE)	A.3. OPCODE = 5 (UPDATE)

	DNS Update [RFC2136] renames the QDCOUNT field to ZOCOUNT, but the	DNS Update [RFC2136] renames the QDCOUNT field to ZOCOUNT, but the
	value is constrained to be one by Section 2.3 ("Zone Section"):	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	"All records to be updated must be in the same zone, and therefore
	the Zone Section is allowed to contain exactly one record.	the Zone Section is allowed to contain exactly one record."

	A.4. OPCODE = 6 (DNS Stateful Operations, DSO)	A.4. OPCODE = 6 (DNS Stateful Operations, DSO)


	DNS Stateful Operations [RFC8490] (DSO - OpCode 6) attempts to	DNS Stateful Operations (DSO) (OpCode 6) [RFC8490] preserves
	preserve compatibility with the standard DNS 12 octet header, and	compatibility with the standard DNS 12-octet header by requiring all
	does so by requiring that all four of the section count values be set	four of the section count values to be set to zero.
	to zero.

	A.5. Conclusion	A.5. Conclusion

	There is no text in [RFC1035] that describes how other parameters in	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	the DNS message, such as AA and RCODE, should be interpreted in the
	where a message includes more than one question. An originator of a	case where a message includes more than one question. An originator
	query with QDCOUNT > 1 can have no expectations of how it will be	of a query with QDCOUNT > 1 can have no expectations of how it will
	processed, and the receiver of a response with QDCOUNT > 1 has no	be processed, and the receiver of a response with QDCOUNT > 1 has no
	guidance for how it should be interpreted.	guidance for how it should be interpreted.

	The allowable values of QDCOUNT seem to be clearly specified for	The allowable values of QDCOUNT seem to be clearly specified for

	OPCODE = 4 (NOTIFY), OPCODE = 5 (UPDATE) and OPCODE = 6 (DNS Stateful	OPCODE = 4 (NOTIFY), OPCODE = 5 (UPDATE), and OPCODE = 6 (DNS
	Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2	Stateful Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and
	(STATUS) is not specified. OPCODE = 3 is reserved.	OPCODE = 2 (STATUS) is not specified. OPCODE = 3 is reserved.

	However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are	However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are
	specified in [RFC1035] without the clarity of normative language, and	specified in [RFC1035] without the clarity of normative language, and
	this looseness of language results in some ambiguity.	this looseness of language results in some ambiguity.


		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.

	Authors' Addresses	Authors' Addresses

	Ray Bellis	Ray Bellis
	Internet Systems Consortium, Inc.	Internet Systems Consortium, Inc.
	PO Box 360	PO Box 360

	Newmarket, NH 03857	Newmarket, NH 03857
	United States of America	United States of America
	Phone: +1 650 423 1300	Phone: +1 650 423 1300
	Email: ray@isc.org	Email: ray@isc.org

	Joe Abley	Joe Abley
	Cloudflare	Cloudflare
	Amsterdam	Amsterdam
	Netherlands	Netherlands
	Phone: +31 6 45 56 36 34	Phone: +31 6 45 56 36 34
	Email: jabley@cloudflare.com	Email: jabley@cloudflare.com

End of changes. 51 change blocks.
	128 lines changed or deleted	124 lines changed or added
This html diff was produced by rfcdiff 1.48.