RFC 9619

RFC 9619: In the DNS, QDCOUNT Is (Usually) One 🎀

okay bestie, this one is RFC 9619 and it's a Standards Track doc 💅 It's published by the IETF, dated July 2024, and its ISSN is 2070-1721. The authors are R. Bellis (ISC) and J. Abley (Cloudflare) 🦋. It updates RFC 1035 and doesn't obsolete anything. So it's basically a patch to the DNS base spec, not a whole new protocol 🧚

Abstract ✨

okay so the tea is that this doc updates RFC 1035 by limiting the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a max of one 💖 It also says what has to happen when a message breaks that rule 🙈

Status of This Memo 📋

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 🌈

for the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9619 🔗

Copyright Notice 🔐

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date. read those carefully, bestie, because they explain your rights and restrictions 📜 Code Components pulled out of this doc have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as the Revised BSD License describes 🫶

Table of Contents 🗺️

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

---

1. Introduction 🌸

okay so the DNS protocol [RFC1034] [RFC1035] has a parameter called QDCOUNT in the DNS message header. Its value is defined as the number of questions in the Question section of a DNS message 💅

now, generally speaking, QDCOUNT is an unsigned 16-bit value, so it could be a pretty wide range of numbers and nobody would be shocked 🤷‍♀️ BUT when we're talking about messages that encode DNS queries and responses (the ones with OPCODE = 0), the protocol has other limits that squeeze QDCOUNT down to either 0 or 1 😭 the big one is that a bunch of response fields, like AA and RCODE, have no defined meaning when there are multiple questions, because there's no way to say which question they're about 💀

so in this doc we:

• take a quick look at the existing written DNS spec
• describe the semantic and practical requirements for DNS queries that naturally limit what QDCOUNT can be
• update the DNS base spec so the allowed values of the QDCODE parameter are clear for DNS messages with OPCODE = 0 ✨

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 doc are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀 so lowercase ones are just regular words, no cap 🙈

3. QDCOUNT Is (Usually) One 👑

there's a short summary of what the existing DNS spec ([RFC1035] and a bunch of other docs) says about QDCOUNT, and you'll find it in Appendix A. the spec is super clear in lots of cases, but there's some ambiguity specifically for OPCODE = 0, and this doc is here to kill that ambiguity 💖

4. Updates to RFC 1035 🦋

this is the main event, bestie 🔥

a DNS message with OPCODE = 0 MUST NOT include a QDCOUNT parameter whose value is greater than 1. so the Question section of a DNS message with OPCODE = 0 MUST NOT contain more than one question. it's giving one question per query, periodt 💅

if a DNS message with OPCODE = 0 and QDCOUNT > 1 shows up, it MUST be treated as an incorrectly formatted message 😭 and the RCODE parameter in the response message MUST be set to 1 (FORMERR). so the server basically says "nope, that's malformed" 🙅‍♀️

middleboxes (like firewalls) that poke at DNS messages to filter out unwanted traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic and return a FORMERR response like described above ✨ those firewalls MUST NOT treat messages with OPCODE = 0 and QDCOUNT = 0 as malformed, though 🙈 that's an important one, bestie. for more guidance, see Section 4 of [RFC8906] 🌈

⚠️ the QDCOUNT = 0 case is NOT malformed for these middleboxes. only QDCOUNT > 1 gets flagged as malformed. don't overfilter your DNS traffic, bestie 😭

more coming in part 2, where we get into Security Considerations, IANA Considerations, the references, and the appendix 🧚💜

A.5. Conclusion

okay bestie, the tea 🍵 There's no text in [RFC1035] that explains how other parameters in the DNS message, like AA and RCODE, should be read when a message has more than one question 😭 So if you send a query with QDCOUNT > 1, you can't have any expectations about how it'll be processed. And if you get a response with QDCOUNT > 1, there's zero guidance on how to interpret it. Lowkey chaotic 💀

The allowable values of QDCOUNT seem clearly specified for OPCODE = 4 (NOTIFY), OPCODE = 5 (UPDATE), and OPCODE = 6 (DNS Stateful Operations, DSO) ✨ OPCODE = 1 (IQUERY) is obsolete, OPCODE = 2 (STATUS) is not specified, and 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. Ngl that's the plot twist 🎭

---

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, and we are so grateful 🫶

Authors' Addresses 🦋

Ray Bellis
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America
Phone: +1 650 423 1300
Email: ray@isc.org


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