Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 9619 ISC
Updates: 1035 J. Abley
Category: Standards Track Cloudflare
ISSN: 2070-1721 July 2024
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.
このドキュメントは、opcode = 0（query）を使用してDNSメッセージのqdcountパラメーターの許可された値を最大1に制約することにより、RFC 1035を更新し、許可されていない値が発生した場合に必要な動作を指定します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9619で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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
The DNS protocol [RFC1034] [RFC1035] 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.
DNSプロトコル[RFC1034] [RFC1035]には、DNSメッセージの質問セクションの質問の数を意味する値が指定されているDNSメッセージヘッダーにパラメーターqdcountが含まれています。
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 as there is no way to signal which question those parameters relate to.
一般的な意味では、QDCountパラメーター（署名されていない16ビット値）がかなりの範囲の値をとることは完全にもっともらしいと思われます。ただし、DNSクエリと応答（OPCODE = 0のメッセージ）をエンコードするメッセージの特定の場合、QDCountの値を0または1のいずれかに制限するプロトコルには、DNSに対して指定されたいくつかのパラメーターを制限するプロトコルに固有の他の制限があります。AAやRcodeなどの応答メッセージには、メッセージが複数のクエリを含む場合、それらのパラメーターがどの質問に関連するかを示す方法がないため、定義された意味はありません。
In this document, we briefly survey the existing written DNS specification; provide a description of the semantic and practical requirements for DNS queries that naturally constrain the allowable values of QDCOUNT; and update the DNS base specification to clarify the allowable values of the QDCODE parameter in the specific case of DNS messages with OPCODE = 0.
このドキュメントでは、既存の書かれたDNS仕様を簡単に調査します。QdCountの許容値を自然に制約するDNSクエリのセマンティックおよび実用的な要件の説明を提供します。DNSベース仕様を更新して、OPCODE = 0を使用してDNSメッセージの特定の場合のQDCodeパラメーターの許容値を明確にします。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
A brief summary of the guidance provided in the existing DNS specification ([RFC1035] and many other documents) for the use of QDCOUNT can be found in Appendix A. While the specification is clear in many cases, there is some ambiguity in the specific case of OPCODE = 0, which this document aims to eliminate.
QDCountの使用に関する既存のDNS仕様（[RFC1035]および他の多くのドキュメント）で提供されるガイダンスの簡単な要約は、付録Aにありますが、多くの場合、仕様は明確ですが、特定のケースには曖昧さがあります。このドキュメントが排除することを目的としているOpCode = 0の。
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.
opcode = 0のDNSメッセージには、値が1より大きいqdcountパラメーターを含めてはなりません。これにより、opcode = 0のDNSメッセージの質問セクションには、1つ以上の質問が含まれていないことがわかります。
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).
opcode = 0およびqdcount> 1を使用したDNSメッセージは、誤ってフォーマットされたメッセージとして扱う必要があります。応答メッセージのrcodeパラメーターの値は、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 [RFC8906] for further guidance.
不要なトラフィックを排除するためにDNSメッセージを処理するミドルボックス（例：ファイアウォール）は、Opcode = 0およびQDCount> 1でメッセージを奇形のトラフィックとして扱い、上記のようにFormerr応答を返す必要があります。このようなファイアウォールは、opcode = 0およびqdcount = 0でメッセージを奇形として扱ってはなりません。さらなるガイダンスについては、[RFC8906]のセクション4を参照してください。
This document clarifies the DNS specification [RFC1035] and aims to improve interoperability between different DNS implementations. In general, the elimination of ambiguity seems well-aligned with security hygiene.
このドキュメントは、DNS仕様[RFC1035]を明確にし、異なるDNS実装間の相互運用性を改善することを目的としています。一般に、あいまいさの排除は、セキュリティ衛生とよく整合しているようです。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
DOI 10.17487/RFC3425, November 2002,
<https://www.rfc-editor.org/info/rfc3425>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>.
[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem
in DNS Servers: Failure to Communicate", BCP 231,
RFC 8906, DOI 10.17487/RFC8906, September 2020,
<https://www.rfc-editor.org/info/rfc8906>.
The DNS specification [RFC1035] provides some guidance about the values of QDCOUNT that are appropriate in various situations. A brief summary of this guidance is collated below.
DNS仕様[RFC1035]は、さまざまな状況で適切なQDCountの値に関するガイダンスを提供します。このガイダンスの簡単な要約を以下に照合します。
[RFC1035] significantly predates the use of the normative requirement key words specified in BCP 14 [RFC2119] [RFC8174], and parts of it are consequently somewhat open to interpretation.
[RFC1035]は、BCP 14 [RFC2119] [RFC8174]で指定されている規範的要件のキーワードの使用よりもかなり前に先立っており、その結果、解釈に対してやや開かれています。
Section 4.1.2 ("Question section format") of [RFC1035] states the following about QDCOUNT:
[RFC1035]のセクション4.1.2（ "質問セクション形式"）は、qdcountについて以下を示しています。
"The section contains QDCOUNT (usually 1) entries"
「セクションにはqdcount（通常1）のエントリが含まれています」
The only documented exceptions within [RFC1035] 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 obsoleted by [RFC3425].
[RFC1035]内の文書化された例外は、リクエストに「空の質問セクション」（QDCount = 0）があり、回答には「QNAMESとして指定されたリソース」の「ゼロ、1つ、または複数のドメイン名があります。質問セクション」。iQueryオペコードは[RFC3425]によって廃止されました。
In the absence of clearly expressed normative requirements, we rely on other text in [RFC1035] that makes use of the definite article or that implies a singular question and, by implication, QDCOUNT = 1.
明確に表明された規範的要件がない場合、明確な記事を使用するか、特異な質問を暗示していることを意味する[RFC1035]の他のテキストに依存しています。
For example, Section 4.1 of [RFC1035] states the following:
たとえば、[RFC1035]のセクション4.1に次のように述べています。
"the question for the name server"
「名前サーバーの質問」
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
"The question section contains fields that describe a question to a name server."
「質問セクションには、名前サーバーへの質問を説明するフィールドが含まれています。」
And per Section 4.1.1 ("Header section format") of [RFC1035]:
および[RFC1035]のセクション4.1.1（ "ヘッダーセクション形式"）ごとに：
"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."
「AA：権威ある回答 - このビットは回答で有効であり、Responsing Name Serverが問題セクションのドメイン名の権限であることを指定します。」
DNS Cookies (Section 5.4 of [RFC7873]) 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 Cookie（[RFC7873]のセクション5.4）により、クライアントは、OpCode = 0およびQDCount = 0のリクエスト（QR = 0）を送信して特定の質問を送信せずに有効なサーバーCookieを受信できるようにします。。
The DNS Zone Transfer Protocol (Section 2.2 of [RFC5936]) allows an authoritative server to optionally send a response message (QR = 1) to a standard Authoritative Transfer (AXFR) query (OPCODE = 0, QTYPE=252) with QDCOUNT = 0 in the second or subsequent message of a multi-message response.
DNSゾーン転送プロトコル（[RFC5936]のセクション2.2）により、権威あるサーバーはオプションで応答メッセージ（QR = 1）を標準の権威ある転送（AXFR）クエリ（opcode = 0、qtype = 252）にqdcount = 0で送信できます。複数メッセージ応答の2番目または後続のメッセージ。
DNS Notify [RFC1996] also lacks a clearly defined range of values for QDCOUNT. Section 3.7 states that:
DNS通知[RFC1996]には、QDCountの明確に定義された値の範囲もありません。セクション3.7は次のように述べています。
"A NOTIFY request has QDCOUNT>0"
「Notifyリクエストにはqdcount> 0があります」
However, all other text in the RFC discusses the <QNAME, QCLASS, QTYPE> tuple in the singular form.
ただし、RFCの他のすべてのテキストでは、<qname、qclass、qtype> tupleについて、単数形で説明しています。
DNS Update [RFC2136] renames the QDCOUNT field to ZOCOUNT, but the value is constrained to be one by Section 2.3 ("Zone Section"):
DNSアップデート[RFC2136]は、QDCountフィールドをZoCountに変更しますが、値はセクション2.3（「ゾーンセクション」）により1つに制限されています。
"All records to be updated must be in the same zone, and therefore the Zone Section is allowed to contain exactly one record."
「更新されるすべてのレコードは同じゾーンにある必要があります。したがって、ゾーンセクションには正確に1つのレコードを含めることができます。」
DNS Stateful Operations (DSO) (OpCode 6) [RFC8490] preserves compatibility with the standard DNS 12-octet header by requiring all four of the section count values to be set to zero.
DNSステートフルオペレーション（DSO）（OPCODE 6）[RFC8490]は、セクションカウント値の4つすべてをゼロに設定することを要求することにより、標準のDNS 12-OCTETヘッダーとの互換性を保持します。
There is no text in [RFC1035] that describes how other parameters 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 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.
[RFC1035]には、AAやRCodeなどのDNSメッセージの他のパラメーターが、メッセージに複数の質問が含まれる場合にどのように解釈されるかを説明するテキストはありません。QDCount> 1を使用したクエリの発信者は、それがどのように処理されるかを期待することはできません。また、QDCount> 1の応答の受信者は、どのように解釈すべきかについてのガイダンスがありません。
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.
QDCountの許容値は、OpCode = 4（Notify）、OpCode = 5（Update）、およびOpCode = 6（DNS Stateful Operations、DSO）に明確に指定されているようです。opcode = 1（iquery）は時代遅れで、opcode = 2（status）は指定されていません。opcode = 3は予約されています。
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.
ただし、opcode = 0（query）のqdcountの許容値は、規範的言語の明確さなしに[rfc1035]で指定されており、この言語の緩みは曖昧さをもたらします。
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.
この文書の説明は、Ted Lemonが提起した質問によって促されました。これは、以前の同様の質問を著者に思い出させ、ペンを拾うように動機付けました。Ondrej Sury、Warren Kumari、Peter Thomassen、Mark Andrews、Lars-Johan Liman、Jim Reid、およびNiall O'Reillyが有用なフィードバックを提供しました。
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