rfc9619.original.xml   rfc9619.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- pre-edited by ST 06/25/24 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.13 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-dnsop-qdcount-is-one-04" number="9619" category="std" consensus="true" sub
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft missionType="IETF" updates="1035" obsoletes="" tocInclude="true" sortRefs="true"
-ietf-dnsop-qdcount-is-one-04" category="std" consensus="true" submissionType="I symRefs="true" version="3" xml:lang="en">
ETF" updates="1035" tocInclude="true" sortRefs="true" symRefs="true" version="3"
>
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title>In the DNS, QDCOUNT is (usually) One</title> <title abbrev="In the DNS, QDCOUNT Is (Usually) One">In the DNS, QDCOUNT Is
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-qdcount-is-one-04" (Usually) One</title>
/> <seriesInfo name="RFC" value="9619"/>
<author initials="R." surname="Bellis" fullname="Ray Bellis"> <author initials="R." surname="Bellis" fullname="Ray Bellis">
<organization abbrev="ISC">Internet Systems Consortium, Inc.</organization > <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization >
<address> <address>
<postal> <postal>
<street>PO Box 360</street> <street>PO Box 360</street>
<city>Newmarket</city> <city>Newmarket</city>
<code>NH 03857</code> <region>NH</region>
<country>US</country> <code>03857</code>
<country>United States of America</country>
</postal> </postal>
<phone>+1 650 423 1300</phone> <phone>+1 650 423 1300</phone>
<email>ray@isc.org</email> <email>ray@isc.org</email>
</address> </address>
</author> </author>
<author initials="J." surname="Abley" fullname="Joe Abley"> <author initials="J." surname="Abley" fullname="Joe Abley">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<city>Amsterdam</city> <city>Amsterdam</city>
<country>NL</country> <country>Netherlands</country>
</postal> </postal>
<phone>+31 6 45 56 36 34</phone> <phone>+31 6 45 56 36 34</phone>
<email>jabley@cloudflare.com</email> <email>jabley@cloudflare.com</email>
</address> </address>
</author> </author>
<date year="2024" month="May" day="29"/> <date year="2024" month="July"/>
<area>Internet</area> <area>OPS</area>
<workgroup>DNSOP Working Group</workgroup> <workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<?line 40?>
<t>This document updates RFC 1035 by constraining the allowed value of the <t>This document updates RFC 1035 by constraining the allowed value of the
QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum
of one, and specifies the required behaviour when values that are not of one, and it specifies the required behavior when values that are not
allowed are encountered.</t> allowed are encountered.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 47?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The DNS protocol <xref target="RFC1034"/><xref target="RFC1035"/> inclu <t>The DNS protocol <xref target="RFC1034"/> <xref target="RFC1035"/> incl
des a parameter udes a parameter
QDCOUNT in the DNS message header, whose value is specified to mean QDCOUNT in the DNS message header whose value is specified to mean
the number of questions in the Question Section of a DNS message.</t> the number of questions in the Question section of a DNS message.</t>
<t>In a general sense it seems perfectly plausible for the QDCOUNT <t>In a general sense, it seems perfectly plausible for the QDCOUNT
parameter, an unsigned 16-bit value, to take a considerable range parameter, an unsigned 16-bit value, to take a considerable range
of values. However, in the specific case of messages that encode of values. However, in the specific case of messages that encode
DNS queries and responses (messages with OPCODE = 0) there are other DNS 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 to be either 0 or 1. In particular, several parameters specified
for DNS response messages such as AA and RCODE have no defined for DNS response messages such as AA and RCODE have no defined
meaning when the message contains multiple queries, since there is meaning when the message contains multiple queries as there is
no way to signal which question those parameters relate to.</t> no way to signal which question those parameters relate to.</t>
<t>In this document we briefly survey the existing written DNS <t>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 the allowable values of the QDCODE parameter in the specific clarify the allowable values of the QDCODE parameter in the specific
case of DNS messages with OPCODE = 0.</t> case of DNS messages with OPCODE = 0.</t>
</section> </section>
<section anchor="terminology-used-in-this-document"> <section anchor="terminology-used-in-this-document">
<name>Terminology used in this document</name> <name>Terminology Used in This Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
and "OPTIONAL" in this document are to be interpreted as described "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, ",
they appear "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="qdcount-is-usually-one"> <section anchor="qdcount-is-usually-one">
<name>QDCOUNT is (usually) One</name> <name>QDCOUNT Is (Usually) One</name>
<t>A brief summary of the guidance provided in the existing DNS <t>A brief summary of the guidance provided in the existing DNS
specification (<xref target="RFC1035" format="default"/> and many other document s) for the use of QDCOUNT can be found in <xref target="Survey"/>. specification (<xref target="RFC1035" format="default"/> and many other document s) for the use of QDCOUNT can be found in <xref target="Survey"/>.
While the specification is clear in many cases, in the specific While the specification is clear in many cases, there is some ambiguity in the s
case of OPCODE = 0 there is some ambiguity which this pecific case of OPCODE = 0, which this
document aims to eliminate.</t> document aims to eliminate.</t>
</section> </section>
<section anchor="updates-to-rfc-1035"> <section anchor="updates-to-rfc-1035">
<name>Updates to RFC 1035</name> <name>Updates to RFC 1035</name>
<t>A DNS message with OPCODE = 0 MUST NOT include a QDCOUNT <t>A DNS message with OPCODE = 0 <bcp14>MUST NOT</bcp14> include a QDCOUNT
parameter whose value is greater than 1. It follows that the Question 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 section of a DNS message with OPCODE = 0 <bcp14>MUST NOT</bcp14> contain more th an
one question.</t> one question.</t>
<t>A DNS message with OPCODE = 0 and QDCOUNT &gt; 1 MUST be treated <t>A DNS message with OPCODE = 0 and QDCOUNT &gt; 1 <bcp14>MUST</bcp14> be
as an incorrectly-formatted message. The value of the RCODE parameter treated
in the response message MUST be set to 1 (FORMERR).</t> as an incorrectly formatted message. The value of the RCODE parameter
<t>Middleboxes (e.g. firewalls) that process DNS messages in order to elim in the response message <bcp14>MUST</bcp14> be set to 1 (FORMERR).</t>
inate unwanted <t>Middleboxes (e.g., firewalls) that process DNS messages in order to eli
traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT &gt; 1 as minate unwanted
traffic <bcp14>SHOULD</bcp14> treat messages with OPCODE = 0 and QDCOUNT &gt; 1
as
malformed traffic and return a FORMERR response as described above. malformed traffic and return a FORMERR response as described above.
Such firewalls MUST NOT treat messages with OPCODE = 0 and QDCOUNT = 0 Such firewalls <bcp14>MUST NOT</bcp14> treat messages with OPCODE = 0 and QDCOUN
as malformed. See Section 4 of <xref target="RFC8906"/> for further guidance.</ T = 0
t> as malformed. See <xref target="RFC8906" sectionFormat="of" section="4"/> for f
urther guidance.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document clarifies the DNS specification and aims to improve <t>This document clarifies the DNS specification <xref target="RFC1035"/>
interoperability between different DNS implementations. In general, and aims to improve
the elimination of ambiguity seems well-aligned with security interoperability between different DNS implementations. In general, the eliminat
ion of ambiguity seems well-aligned with security
hygiene.</t> hygiene.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>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.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
<front> 34.xml"/>
<title>Domain names - concepts and facilities</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris 35.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<date month="November" year="1987"/> 19.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<t>This RFC is the revised basic definition of The Domain Name Sys 74.xml"/>
tem. It obsoletes RFC-882. This memo describes the domain style names and their <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.34
used for host address look up and electronic mail forwarding. It discusses the c 25.xml"/>
lients and servers in the domain name system and the protocol used between them.
</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and forma
t used in the implementation of the Domain Name System. It obsoletes RFC-883. Th
is memo documents the details of the domain name client - server communication.<
/t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC3425" target="https://www.rfc-editor.org/info/rfc3
425" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3425.xml">
<front>
<title>Obsoleting IQUERY</title>
<author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
<date month="November" year="2002"/>
<abstract>
<t>The IQUERY method of performing inverse DNS lookups, specified
in RFC 1035, has not been generally implemented and has usually been operational
ly disabled where it has been implemented. Both reflect a general view in the co
mmunity that the concept was unwise and that the widely-used alternate approach
of using pointer (PTR) queries and reverse-mapping records is preferable. Conseq
uently, this document deprecates the IQUERY operation, declaring it entirely obs
olete. This document updates RFC 1035. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3425"/>
<seriesInfo name="DOI" value="10.17487/RFC3425"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8906" target="https://www.rfc-editor.org/info/rfc8
906" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8906.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
<front> 06.xml"/>
<title>A Common Operational Problem in DNS Servers: Failure to Commu <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.78
nicate</title> 73.xml"/>
<author fullname="M. Andrews" initials="M." surname="Andrews"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<author fullname="R. Bellis" initials="R." surname="Bellis"/> 36.xml"/>
<date month="September" year="2020"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.19
<abstract> 96.xml"/>
<t>The DNS is a query/response protocol. Failing to respond to que <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
ries, or responding incorrectly, causes both immediate operational problems and 36.xml"/>
long-term problems with protocol development.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<t>This document identifies a number of common kinds of queries to 90.xml"/>
which some servers either fail to respond or respond incorrectly. This document
also suggests procedures for zone operators to apply to identify and remediate
the problem.</t>
<t>The document does not look at the DNS data itself, just the str
ucture of the responses.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="231"/>
<seriesInfo name="RFC" value="8906"/>
<seriesInfo name="DOI" value="10.17487/RFC8906"/>
</reference>
<reference anchor="RFC7873" target="https://www.rfc-editor.org/info/rfc7
873" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml">
<front>
<title>Domain Name System (DNS) Cookies</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="M. Andrews" initials="M." surname="Andrews"/>
<date month="May" year="2016"/>
<abstract>
<t>DNS Cookies are a lightweight DNS transaction security mechanis
m that provides limited protection to DNS servers and clients against a variety
of increasingly common denial-of-service and amplification/ forgery or cache poi
soning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (N
etwork Address Translation - Protocol Translation), and anycast and can be incre
mentally deployed. (Since DNS Cookies are only returned to the IP address from w
hich they were originally received, they cannot be used to generally track Inter
net users.)</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7873"/>
<seriesInfo name="DOI" value="10.17487/RFC7873"/>
</reference>
<reference anchor="RFC5936" target="https://www.rfc-editor.org/info/rfc5
936" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml">
<front>
<title>DNS Zone Transfer Protocol (AXFR)</title>
<author fullname="E. Lewis" initials="E." surname="Lewis"/>
<author fullname="A. Hoenes" initials="A." role="editor" surname="Ho
enes"/>
<date month="June" year="2010"/>
<abstract>
<t>The standard means within the Domain Name System protocol for m
aintaining coherence among a zone's authoritative name servers consists of three
mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defin
ed in RFC 1034 and RFC 1035.</t>
<t>The definition of AXFR has proven insufficient in detail, there
by forcing implementations intended to be compliant to make assumptions, impedin
g interoperability. Yet today we have a satisfactory set of implementations that
do interoperate. This document is a new definition of AXFR -- new in the sense
that it records an accurate definition of an interoperable AXFR mechanism. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5936"/>
<seriesInfo name="DOI" value="10.17487/RFC5936"/>
</reference>
<reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1
996" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml">
<front>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTI
FY)</title>
<author fullname="P. Vixie" initials="P." surname="Vixie"/>
<date month="August" year="1996"/>
<abstract>
<t>This memo describes the NOTIFY opcode for DNS, by which a maste
r server advises a set of slave servers that the master's data has been changed
and that a query should be initiated to discover the new data. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1996"/>
<seriesInfo name="DOI" value="10.17487/RFC1996"/>
</reference>
<reference anchor="RFC2136" target="https://www.rfc-editor.org/info/rfc2
136" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title
>
<author fullname="P. Vixie" initials="P." role="editor" surname="Vix
ie"/>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="J. Bound" initials="J." surname="Bound"/>
<date month="April" year="1997"/>
<abstract>
<t>Using this specification of the UPDATE opcode, it is possible t
o add or delete RRs or RRsets from a specified zone. Prerequisites are specified
separately from update operations, and can specify a dependency upon either the
previous existence or nonexistence of an RRset, or the existence of a single RR
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2136"/>
<seriesInfo name="DOI" value="10.17487/RFC2136"/>
</reference>
<reference anchor="RFC8490" target="https://www.rfc-editor.org/info/rfc8
490" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml">
<front>
<title>DNS Stateful Operations</title>
<author fullname="R. Bellis" initials="R." surname="Bellis"/>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Pusateri" initials="T." surname="Pusateri"/>
<date month="March" year="2019"/>
<abstract>
<t>This document defines a new DNS OPCODE for DNS Stateful Operati
ons (DSO). DSO messages communicate operations within persistent stateful sessio
ns using Type Length Value (TLV) syntax. Three TLVs are defined that manage sess
ion timeouts, termination, and encryption padding, and a framework is defined fo
r extensions to enable new stateful operations. This document updates RFC 1035 b
y adding a new DNS header OPCODE that has both different message semantics and a
new result code. This document updates RFC 7766 by redefining a session, provid
ing new guidance on connection reuse, and providing a new mechanism for handling
session idle timeouts.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8490"/>
<seriesInfo name="DOI" value="10.17487/RFC8490"/>
</reference>
</references> </references>
</references> </references>
<?line 124?>
<section anchor="Survey"> <section anchor="Survey">
<name>Guidance for the use of QDCOUNT in the DNS Specification</name> <name>Guidance for the Use of QDCOUNT in the DNS Specification</name>
<t>The DNS Specification provides some guidance about the values of <t>The DNS specification <xref target="RFC1035"/> provides some guidance a
bout the values of
QDCOUNT that are appropriate in various situations. A brief summary QDCOUNT that are appropriate in various situations. A brief summary
of this guidance is collated below.</t> of this guidance is collated below.</t>
<section anchor="opcode-0-query-and-1-iquery"> <section anchor="opcode-0-query-and-1-iquery">
<name>OPCODE = 0 (QUERY) and 1 (IQUERY)</name> <name>OPCODE = 0 (QUERY) and 1 (IQUERY)</name>
<t><xref target="RFC1035"/> significantly predates the use of the normat <t><xref target="RFC1035"/> significantly predates the use of the normat
ive requirements ive requirement
keywords specified in BCP 14 <xref target="RFC2119" format="default"/> <xref tar key words specified in BCP 14 <xref target="RFC2119" format="default"/> <xref ta
get="RFC8174" format="default"/>, and parts of it are consequently somewhat open rget="RFC8174" format="default"/>, and parts of it are consequently somewhat ope
to n to interpretation.</t>
interpretation.</t> <t>Section <xref target="RFC1035" sectionFormat="bare" section="4.1.2">"
<t>Section 4.1.2 ("Question section format") has this to say about Question section format"</xref> of <xref target="RFC1035"/> states the following
QDCOUNT:</t> about QDCOUNT:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>The section contains QDCOUNT (usually 1) entries</t> <t>"The section contains QDCOUNT (usually 1) entries"</t>
</li> </li>
</ul> </ul>
<t>The only documented exceptions within <xref target="RFC1035"/> relate to the IQuery <t>The only documented exceptions within <xref target="RFC1035"/> relate to the IQuery
Opcode, where the request has "an empty question section" (QDCOUNT = 0), OpCode, where the request has "an empty question section" (QDCOUNT = 0),
and the response has "zero, one, or multiple domain names for the and the response has "zero, one, or multiple domain names for the
specified resource as QNAMEs in the question section". The IQuery OpCode specified resource as QNAMEs in the question section". The IQuery OpCode
was made obsolete in <xref target="RFC3425"/>.</t> was obsoleted by <xref target="RFC3425"/>.</t>
<t>In the absence of clearly expressed normative requirements, we rely <t>In the absence of clearly expressed normative requirements, we rely on other
on other text in <xref target="RFC1035"/> that makes use of the definite article text in <xref target="RFC1035"/> that makes use of the definite article or that
or other text that implies a singular question and, by implication, implies a singular question and, by implication, QDCOUNT = 1.</t>
QDCOUNT = 1.</t> <t>For example, <xref target="RFC1035" sectionFormat="of" section="4.1"/
<t>For example, Section 4.1:</t> > states the following:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>the question for the name server</t> <t>"the question for the name server"</t>
</li> </li>
</ul> </ul>
<t>and:</t> <t>and</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>The question section contains fields that describe a question to <t>"The question section contains fields that describe a question to
a a
name server</t> name server."</t>
</li> </li>
</ul> </ul>
<t>and in Section 4.1.1. ("Header section format"):</t> <t>And per Section <xref target="RFC1035" sectionFormat="bare" section=" 4.1.1">"Header section format"</xref> of <xref target="RFC1035"/>:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>AA Authoritative Answer - this bit is valid in responses, <t>"AA: Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an and specifies that the responding name server is an
authority for the domain name in question section.</t> authority for the domain name in question section."</t>
</li> </li>
</ul> </ul>
<t>DNS Cookies <xref target="RFC7873"/> in Section 5.4 allow a client to <t>DNS Cookies (<xref target="RFC7873" sectionFormat="of" section="5.4"/
receive >) allow a client to receive a valid Server Cookie without sending a specific qu
a valid Server Cookie without sending a specific question by sending estion by sending
a request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting a request (QR = 0) with OPCODE = 0 and QDCOUNT = 0, with the resulting
response also containing no question.</t> response also containing no question.</t>
<t>DNS Zone Transfer Protocol (AXFR) <xref target="RFC5936"/> in Section
2.2 allows <t>The DNS Zone Transfer Protocol (<xref target="RFC5936" sectionFormat=
an authoritative server optionally to send a response message "of" section="2.2"/>) allows an authoritative server to optionally send a respon
(QR = 1) to a standard AXFR query (OPCODE = 0, QTYPE=252) with se message
(QR = 1) to a standard Authoritative Transfer (AXFR) query (OPCODE = 0, QTYPE=25
2) with
QDCOUNT = 0 in the second or subsequent message of a multi-message QDCOUNT = 0 in the second or subsequent message of a multi-message
response.</t> response.</t>
</section> </section>
<section anchor="opcode-4-notify"> <section anchor="opcode-4-notify">
<name>OPCODE = 4 (NOTIFY)</name> <name>OPCODE = 4 (NOTIFY)</name>
<t>DNS Notify <xref target="RFC1996"/> also lacks a clearly defined rang e of values <t>DNS Notify <xref target="RFC1996"/> also lacks a clearly defined rang e of values
for QDCOUNT. Section 3.7 says:</t> for QDCOUNT. Section <xref target="RFC1996" sectionFormat="bare" section
="3.7"/> states that:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>A NOTIFY request has QDCOUNT &gt; 0</t> <t>"A NOTIFY request has QDCOUNT&gt;0"</t>
</li> </li>
</ul> </ul>
<t>but all other text in the RFC talks about the &lt;QNAME, QCLASS, QTYP <t>However, all other text in the RFC discusses the &lt;QNAME, QCLASS, Q
E&gt; TYPE&gt;
tuple in the singular.</t> tuple in the singular form.</t>
</section> </section>
<section anchor="opcode-5-update"> <section anchor="opcode-5-update">
<name>OPCODE = 5 (UPDATE)</name> <name>OPCODE = 5 (UPDATE)</name>
<t>DNS Update <xref target="RFC2136"/> renames the QDCOUNT field to ZOCO UNT, but <t>DNS Update <xref target="RFC2136"/> renames the QDCOUNT field to ZOCO UNT, but
the value is constrained to be one by Section 2.3 ("Zone Section"):</t> the value is constrained to be one by Section <xref target="RFC2136" sectionForm at="bare" section="2.3">"Zone Section"</xref>:</t>
<ul empty="true"> <ul empty="true">
<li> <li>
<t>All records to be updated must be in the same zone, and therefore <t>"All records to be updated must be in the same zone, and therefor
the e the
Zone Section is allowed to contain exactly one record.</t> Zone Section is allowed to contain exactly one record."</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="opcode-6-dns-stateful-operations-dso"> <section anchor="opcode-6-dns-stateful-operations-dso">
<name>OPCODE = 6 (DNS Stateful Operations, DSO)</name> <name>OPCODE = 6 (DNS Stateful Operations, DSO)</name>
<t>DNS Stateful Operations <xref target="RFC8490"/> (DSO - OpCode 6) att
empts to <t>DNS Stateful Operations (DSO) (OpCode 6) <xref target="RFC8490"/>
preserve compatibility with the standard DNS 12 octet header, and preserves compatibility with the standard DNS 12-octet header by requiring all f
does so by requiring that all four of the section count values be our of the section count values to be set to zero.</t>
set to zero.</t>
</section> </section>
<section anchor="conclusion"> <section anchor="conclusion">
<name>Conclusion</name> <name>Conclusion</name>
<t>There is no text in <xref target="RFC1035"/> that describes how other parameters <t>There is no text in <xref target="RFC1035"/> that describes how other parameters
in the DNS message such as AA, RCODE should be interpreted in the in the DNS message, such as AA and RCODE, should be interpreted in the
case where a message includes more than one question. An originator case where a message includes more than one question. An originator
of a query with QDCOUNT &gt; 1 can have no expectations of how it will of a query with QDCOUNT &gt; 1 can have no expectations of how it will
be processed, and the receiver of a response with QDCOUNT &gt; 1 has be processed, and the receiver of a response with QDCOUNT &gt; 1 has
no guidance for how it should be interpreted.</t> no guidance for how it should be interpreted.</t>
<t>The allowable values of QDCOUNT seem to be clearly specified for <t>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 Stateful
Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2 Operations, DSO). OPCODE = 1 (IQUERY) is obsolete and OPCODE = 2
(STATUS) is not specified. OPCODE = 3 is reserved.</t> (STATUS) is not specified. OPCODE = 3 is reserved.</t>
<t>However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are <t>However, the allowable values of QDCOUNT for OPCODE = 0 (QUERY) are
specified in <xref target="RFC1035"/> without the clarity of normative language, specified in <xref target="RFC1035"/> without the clarity of normative language,
and this looseness of language results in some ambiguity.</t> and this looseness of language results in some ambiguity.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The clarifications in this document were prompted by questions posed
by <contact fullname="Ted Lemon"/>, which reminded the authors of earlier, simil
ar questions
and motivated them to pick up their pens. <contact fullname="Ondrej Sury"/>, <co
ntact fullname="Warren Kumari"/>, <contact fullname="Peter Thomassen"/>, <contac
t fullname="Mark Andrews"/>, <contact fullname="Lars-Johan Liman"/>, <contact fu
llname="Jim Reid"/>, and <contact fullname="Niall O'Reilly"/> provided useful fe
edback.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA5VZ2XYbNxJ9x1dglIeRzpA8ojbHymRhJDl2RhZlUTqZ5A3s
BkVEvaXRLZrx8b/kW/Jlc6uwdJOSZjIPPiKbDaCWW7duwcPhUDSmyfSpfFfI
Zqnl+dVsID+cn03vrm6lsXK3ta3KsvWenBZapGVSqBxvp7VaNEOjm8UwLWxZ
DX9Lk7It8MgOy0IP9w9FW6Wq0fZU3rw5G+8fHgth23lurDVl0awrOvLi9o0w
VX0qm7q1zcH+/uv9A6FqrcicRteFbsTq/pSMml7Ln8r6wRT38oe6bCvxsOpe
Gp6TOSJRzam0TSpEUqZ481S2dqhsYoyozKmQciibMuG/dp3XemHd57Ju+ItQ
bbMsa34T/6Q0BZk/kt/rLDOWHzn3b9S6/7Cs7ztj5GxtG51beVYWtLVp8wF+
TEb8qprPa/2It2dn/N3iaA2zr6fy+/KjPDzZ58eJadan8kqvclU/IAr8rExx
9NVbuX/45fEr/wgxr/Hm3Yy/V0sE/1T+YyxPjvfl0cGhHB/uux11rkx2Kmu1
/s7YZASTN938cSQn80yve17+WOreM3byLCvbdJEhRz0zJzkcrlOVb9p0dblh
0yGMkkfH8vgEXsrDo75Vvyo65rsk7j5KylyI4XCIgCFEKmmEuF0Cj0Bgm+ui
kR5ehC5J8JLzNY4u6GVTEEwIzUBuudKpfFRZq2W5oIcioLtSNdyE5QgAQUzm
2lp1jz1XplnK6fXZ9PxCfi335e6Hu4ubn/eAHqlkrj6avM0FdoNjA6mKVNpK
J2ZhsJROrfVvralx7Fwv1aMp21qulrpwVtArqpHwURZlI4KF9F0XHDuNpSPn
fG7SNNNCfEHoqsu0TRpUD4WCK1VWdQlEl5n89OlvrsyOPn+On48/f4ZrSdam
OFV1/sYImFjzwXe51CrV9QAGl1b7uCHswcGUYpBrVQhaWLT5HOFDJH6DY2Sa
DXt+8A/kTLPN9JIKp8A70I2S97rQtcqk1QUOMw0+UOFUul5gVbaWVaZaa4AN
uShrt68zXURnKAGyLay5L2Dd+GQ4xz5s94BsbdQDYMDIMHCMcIYaKO415c8l
ZCTfIgWPtJU33nubyERZhk1EBueO8pRqQWGD3zWlnUBQa1vhGHzbfQlJe7Q9
Mk3ZLumjyExuGhVCRz8C296MmF0+NYI74Ah2hWjA0TnwY2hL4BWxGo+I0RGl
xiQtKmqA2D5ysGPkelkVFF7yJ/jQeWzbZCmVlZMJO3nDrgDWBF+Z6oVB2AUh
gmqOYU6mBzjB6AYmW5m3WWMqBN9HDPYAmtrHAzyK3VZgVXhCqYSdq6XByQFY
eJEA2TO+1hkIAAscmpoNdlhpOccxC2DItvWjXrNV+qPBZmRnbZpGc9WLkGxO
wle0EnF/BFgAGxROUpsqAJixAcoqEFSORkXMhKWZ8DVPh1sZohnQwfkrVNPW
1Ep7mYwcRbgUT/L6FR8CixzZxWKdEyw37EYYRII0m8V6c9MeWEL5IH8b1NdH
vAiI/yt8OCJiutV1booyK+/XaLcoQbOVC8dWD0jBqqxTK3fe381udwbur7ya
8uebiw93724uzunz7O3k8jJ+cG8IfJneXfrf6VO38mz6/v3F1blbjKdy69H7
yc/YgCK5M72+fTe9mlzuPLGSS9KVkSEKrmqEJyXgOwzMgXKs+f7sWo6PPN0e
jMevQbHuy5fjV+BergDXE8oCqXZfEeG1VFWlVU2bIDlglgp1n6EOcIRdlqtC
UiVwSF+UX2LiUA1M5xAG65DV+9akiqrJIzcNaY2AfwL0SKity3c4MwGbzolu
24J3+fRpxvXz+fNI/LQ0md6Ai9sKdiYZfKP3URxrpk37hE0jtp7rrJ4GIMZy
oDefG/jUrD0JUKZElymDHoFUaeJOVJUL2p3XA/ghSAKKV7+3vdTWAxBDs0Th
P2kz2w3xHiqVHqO0CybbBjGjovPV3u+BYqMH/jeLoiWeN2VeEixxhoDWiGQ4
+queEQ5DZr+RY7c/0tuw9alQ1LnI7bKuueMOAYtcNQT90KulpPrtKyjfBDo9
4RO93TzicRaqGHkZy90305v3Fzc3RB1vQJcrYNsHDNBNsGyTeLAxOIPC3Es3
uv0KFAzzQaILatOeEdirl1lrOxjKilxl5DDJGr+Va+RgatIn3trOsT4dQJmW
j8DejBrkIjoTU/h/WIPvlIpoDWI+0zpKpyOK+6dP3xLLvN4/ActQ8S7amtt9
KH6uAixpayqcsyB4WFpsi2fXKoJepZBvVjQZF8rM5MQqWjAtlhVpKJPREXPd
rDSaaGoWC6dbaCO8nnEbdCezDPE6b8CiMeQxFESsdSf+Vhirhipzco6DZr1P
Yrm+N9iJHP3zj3eTq8n/8HKJmEJW8JsqceZQkCbJQ1GuMp3eu37tOpSPSaJ6
OnZTUtRMsHlF1YFpo9O8FaghFXh0i18udV4WA89cUASmIELmpszjJfdisGVm
SHFaBAMHd5txo8rLxjxShdK6nLJQmeQBMoC+mxoKmSI7LdJa/ypB0OuB/Emh
hAv5rxaNwQzENZPW7bLMlbXUg95jkJQTWrECNV+q2g5/LIm8Lg04eyB/NLm8
0Sbl3F8ZYFlM/44HJFhiW0GzWLSZXGidzlXy4KcU+khx/SG0oRd6S2/cmG3A
7dMXvsl0k83mC94A3x5iu0MFto5qo8qJs02cstB3AdvaEHOweK4xkWEn07QB
olttVTDNEcmHg6jDgd05I3MNliccffES44Ln3rmvQmwMY6Rs2amChxvMea5l
daEqmH7NYxwiHUChnlg8OWVBqp5RZJyHpCfxtuZdKUIr8h2lyrIwyhnlW0ek
ldF4dCB3d+KoZv0Prgfs7HEBcSBIlUOcc7xDhE+F+IZbQ1gWtX5IQRAvcryH
makhKewSzNIoFBZCqj8munKlRBXPsqMXtqj0OVLvYC9yNK1oCKM607WOYzc8
Yat3AGyNSu2qNJi5g1R1tLvnhOFG9+L1v4PrBm7AB5jj9JKinmAe3Y/YAHPR
DcfYA9N+wo3iw9Xk/UWch5+YMeLYOWfktDqjiXLFTQACpJzbMtMOsC4Uh0cH
x6TBhL+nU3NUdcKYYe2FgOqPyLIlCf48igY0SSCWwHfhpk/Z6I+N3A43V06O
udkGVNKBPOqZhmZXTDyYVuB8bxNeRNzP0zANd/dtn9cIuANiTX7HlfVAdJkY
kyLAlvqjogYykD2UMtI2ghgIhvKAiII7akGJjJjcDncHTuQpS73mCL0cBndz
ZikVNtnemaLULxxIvt2dt3xZ8qRu2ArMyxPmex7vkYpJYdFC6A6SKopuKfAH
vGV473h5MMBauifculXyktK9RpebfQtpJ0hEt9Afuo5B6mGWTtoODQJPhHtW
lg90lNMZr758dci3R9Hp49GRmyrpNgVZLljSQTVqOCeU92Tm7HGbcTETQwOq
bLLqblaiFfN1+BmbuGqo0E+gGHddVbh7E1YCvcIduCc+JlSe2KDTaZktQ8o5
VmVfO5O7v5Cevq1VYaFd5HW4admd/PvNzZ4PwvHrw5PNIByAMDkI1KZjqF1+
fSpKJjKmPWJNTUrqiTIWux9uCPT+StE2SLeqU0mn863Buu/9QH64/fn64uuD
4wMXiF7d7McpS8PflMjKtnPfDqIQd5dvFKVhsCCYtNXJjuQuxOu7N9S7KE5X
UCKLtQ/I+PVrCghHN0OSLGPBsY+/CnKXazJervHNkjeXZa0L5OHoFXUU60pF
uiM3GLxT6vtCzAEimpo3WYtHEcx6mKPJlCgG/snUi6idXU5mMx+9b0TTEoOH
cHmCYvf//CP6fyx3767PJ7cX3n83Vnr/D8YMCOgs5v/efaSjFcrmL1N+AK5D
q4zSxCkIf+3jblHn1Ac14b9D1yFIhZHpHwUugeuoNL4+cSvdhRCEYotwzTuv
qMZ/j9fSPFUv3AipsU9/a+YMf/ncxGIh/uWbV3rTHbkFkBO5y/oMqGctOK2C
/B7I89nUh+2Zn8MEc/R6HzHcxbvgQg/yEwgnDJ1o2OSgoD5G1QSr8gqr/cAR
Kz7WCx01PpBl0oAvwtU1fhNpyWKRoutaoPsfAeVgtKAr+XifFxpEWzRBR87R
1N3MSjrARQCzRpK1Nty/u+sKEMvLPTS0FyuXoE2H3e4CU5int+/dZevAD9kW
BJql29dSbqm7UHECKN6tdzf+8e5AbtwdoBGBJcw9zWBlLZgaHOVscCxNyHQZ
FK56oS4QKZ9KLCKX0MNWGBDEXIfxXacReaE31I59IgU+OQXVTre/9/3pwe/+
rPcjJyKfu+IM29Io6Ssl8FMn0rC/eIbvBvIZEmBnXsK+2Mb+qHu1mwEIJlHP
bWx3IHZnt5Pbu9meg1LTGdnb6ZB+9AVBvsf/rHjpnjdSEuL43IRS9xUrA/fb
DrihZTdhIm7Wm3NJBn5vgbMgnGFcVmL+LejyBm+G331bZgG8eakHH/4DC9TU
d3geAAA=
</rfc> </rfc>
 End of changes. 50 change blocks. 
422 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.48.