ietf-corpus

rfc-9619

In the DNS, QDCOUNT Is (Usually) One

R. Bellis, J. Abley
date2024-07 streamIETF areaops wgdnsop statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc9619 doi10.17487/RFC9619 errataview
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 it specifies the required behavior when values that are not allowed are encountered.

updates

Extracted elements (14)

design-rationale §A.5

An originator of a query with QDCOUNT > 1 can have no expectations of how it will be processed, and a receiver of a response with QDCOUNT > 1 has no guidance for interpretation. The specification therefore standardizes rejection rather than defining multi-question semantics.

dns

design-rationale §1

Multiple questions are disallowed in OPCODE = 0 messages because response parameters such as AA (Authoritative Answer) and RCODE have no defined meaning when a message contains multiple questions — there is no mechanism to signal which question those parameters relate to.

dns

design-rationale §A.1

RFC 1035 predates the normative key words of BCP 14 (RFC 2119), so its QDCOUNT guidance for OPCODE = 0 lacked clear normative language. This document eliminates that ambiguity by expressing the constraint explicitly with MUST NOT.

dns, process

interoperability-note §A.1

DNS Cookies (RFC 7873, Section 5.4) permit a client to receive a valid Server Cookie by sending OPCODE = 0 with QDCOUNT = 0 and no question; the response also contains no question. This is a defined, valid use of QDCOUNT = 0.

dns

interoperability-note §A.4

DNS Stateful Operations (OPCODE = 6, RFC 8490) requires all four section count fields — including QDCOUNT — to be set to zero to preserve compatibility with the standard 12-octet DNS header.

dns

interoperability-note §A.2

For OPCODE = 4 (NOTIFY, RFC 1996), QDCOUNT > 0 is required; all other text discusses the <QNAME, QCLASS, QTYPE> tuple in singular form, implying QDCOUNT = 1 in practice.

dns

interoperability-note §A.3

For OPCODE = 5 (UPDATE, RFC 2136), the QDCOUNT field is renamed ZOCOUNT and constrained to exactly one by the requirement that all records to be updated must be in the same zone.

dns

interoperability-note §A.1

The DNS Zone Transfer Protocol (RFC 5936, Section 2.2) allows an authoritative server to send response messages with QDCOUNT = 0 in the second or subsequent messages of a multi-message AXFR response.

dns

normative-requirement §4 MUST

A DNS message with OPCODE = 0 and QDCOUNT > 1 MUST be treated as an incorrectly formatted message. The RCODE in the response MUST be set to 1 (FORMERR).

dns

normative-requirement §4 MUST NOT

A DNS message with OPCODE = 0 (QUERY) MUST NOT include a QDCOUNT parameter whose value is greater than 1. It follows that the Question section of such a message MUST NOT contain more than one question.

dns

normative-requirement §4 MUST NOT

Middleboxes MUST NOT treat DNS messages with OPCODE = 0 and QDCOUNT = 0 as malformed; QDCOUNT = 0 is a valid and defined case for OPCODE = 0.

dns

normative-requirement §4 SHOULD

Middleboxes such as firewalls that process DNS messages SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic and return a FORMERR response.

dns, security

protocol-element §1

QDCOUNT is an unsigned 16-bit field in the DNS message header whose value specifies the number of questions in the Question section. For OPCODE = 0 (QUERY), this document constrains the allowed values to 0 or 1.

dns

security-consideration §5

Clarifying the DNS specification to remove ambiguity around QDCOUNT improves interoperability and is well-aligned with security hygiene. Consistent rejection of QDCOUNT > 1 with FORMERR reduces the attack surface for malformed-message abuse.

dns, security