]> Internet Systems Consortium, Inc.

PO Box 360 Newmarket NH 03857 US +1 650 423 1300 ray@isc.org

Cloudflare

Amsterdam NL +31 6 45 56 36 34 jabley@cloudflare.com

Internet DNSOP Working Group Internet-Draft 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.

Introduction The DNS protocol 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.

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 when, and only when, they appear in all capitals, as shown here.

QDCOUNT is (usually) One A brief summary of the guidance provided in the existing DNS specification ( and many other documents) for the use of QDCOUNT can be found in . 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.

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 for further guidance.

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.

IANA Considerations This document has no IANA actions.

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.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK] Informative References The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development. This document identifies a number of common kinds of queries to 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. The document does not look at the DNS data itself, just the structure of the responses. DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.) The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding 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. [STANDARDS-TRACK] This memo describes the NOTIFY opcode for DNS, by which a master 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] Using this specification of the UPDATE opcode, it is possible to 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] This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by 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, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.

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.

OPCODE = 0 (QUERY) and 1 (IQUERY) significantly predates the use of the normative requirements keywords specified in BCP 14 , 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 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 . In the absence of clearly expressed normative requirements, we rely on other text in 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:

• 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 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) 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.

OPCODE = 4 (NOTIFY) DNS Notify 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.

OPCODE = 5 (UPDATE) DNS Update 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.

OPCODE = 6 (DNS Stateful Operations, DSO) DNS Stateful Operations (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.

Conclusion There is no text in 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 without the clarity of normative language, and this looseness of language results in some ambiguity.