Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 10029 ISC
Category: Standards Track July 2026
ISSN: 2070-1721
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the Question section of a DNS QUERY (OpCode=0).
この文書では、DNS クライアントが、DNS クエリ (OpCode=0) の質問セクションで指定されたプライマリ レコード タイプと一緒に配信される追加の DNS レコード タイプを要求する方法を指定します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10029.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10029 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Specification
3.1. Multiple QTYPE EDNS Options Format
3.2. Client Request Generation
3.3. Server Request Parsing
3.4. Server Response Generation
3.5. Client Response Processing
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Examples
A.1. Stub Query for A with MQTYPE-Query for AAAA and HTTPS
A.2. Stub Query for DS with MQTYPE-Query for DNSKEY
A.3. Recursive Query for DS with MQTYPE-Query for NS
Acknowledgements
Author's Address
A commonly requested DNS [STD13] feature is the ability to receive multiple related resource records (RRs) in a single DNS response.
一般的に要求される DNS [STD13] 機能は、単一の DNS 応答で複数の関連リソース レコード (RR) を受信する機能です。
For example, it may be desirable to receive the A, AAAA, and HTTPS RRs for a domain name together, rather than having to issue multiple queries.
たとえば、複数のクエリを発行するよりも、ドメイン名の A、AAAA、および HTTPS RR をまとめて受信する方が望ましい場合があります。
The DNS wire protocol in theory supported having multiple questions in a single packet, but in practice this does not work. [RFC9619] updates RFC 1035 [STD13] to only permit a single question in a QUERY (OpCode=0) request.
DNS ワイヤー プロトコルは、理論上は 1 つのパケットに複数の質問を含めることをサポートしていましたが、実際には機能しません。[RFC9619] は、QUERY (OpCode=0) リクエストで単一の質問のみを許可するように RFC 1035 [STD13] を更新します。
Sending QTYPE=ANY does not guarantee that all resource record sets (RRsets) will be returned. Section 4.1 of [RFC8482] specifies that responders may return a single RRset of their choosing.
QTYPE=ANY を送信しても、すべてのリソース レコード セット (RRset) が返されることは保証されません。[RFC8482] のセクション 4.1 では、応答側が選択した単一の RRset を返すことができると規定されています。
This document provides a solution for those cases where only the QTYPE varies by specifying a new option for the Extension Mechanisms for DNS (EDNS) [RFC6891] that contains an additional list of QTYPE values that the client wishes to receive in addition to the single QTYPE appearing in the Question section. A different EDNS option is used in response packets as protection against DNS middleboxes that echo EDNS options verbatim.
この文書は、質問セクションに表示される単一の QTYPE に加えて、クライアントが受信を希望する QTYPE 値の追加リストを含む、DNS 拡張メカニズム (EDNS) [RFC6891] の新しいオプションを指定することにより、QTYPE のみが変化する場合の解決策を提供します。EDNS オプションをそのままエコーする DNS ミドルボックスに対する保護として、応答パケットでは別の EDNS オプションが使用されます。
The specification described herein is applicable both for queries from a stub resolver to recursive servers, and from recursive resolvers to authoritative servers. It does not apply to Multicast DNS queries [RFC6762], which are already designed to allow requesting multiple records in a single query, but it is applicable to DNS-Based Service Discovery (DNS-SD) [RFC6763].
ここで説明する仕様は、スタブリゾルバから再帰サーバーへのクエリと、再帰リゾルバから権威サーバーへのクエリの両方に適用できます。これは、単一のクエリで複数のレコードを要求できるようにすでに設計されているマルチキャスト DNS クエリ [RFC6762] には適用されませんが、DNS-Based Service Discovery (DNS-SD) [RFC6763] には適用できます。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document makes use of DNS terminology defined in [RFC9499].
この文書では、[RFC9499] で定義されている DNS 用語を使用します。
The overall format of an EDNS option is shown for reference in Figure 1, per [RFC6891], followed by the option-specific data.
参考のために、[RFC6891] に従って EDNS オプションの全体的な形式を図 1 に示し、その後にオプション固有のデータを示します。
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
: OPTION-DATA :
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: EDNS Option Format
図 1: EDNS オプションの形式
OPTION-CODE:
オプションコード:
MQTYPE-Query (20) in queries and MQTYPE-Response (21) in responses.
クエリ内の MQTYPE-Query (20) と応答内の MQTYPE-Response (21)。
OPTION-LENGTH:
オプションの長さ:
Size (in octets) of OPTION-DATA.
OPTION-DATA のサイズ (オクテット単位)。
OPTION-DATA:
オプションデータ:
Option specific, as depicted in Figure 2.
図 2 に示すように、オプション固有。
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | QT1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
: ... :
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QTn |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: MQTYPE OPTION-DATA Format
図 2: MQTYPE OPTION-DATA 形式
The OPTION-DATA is a list of 2-octet values in network order, most significant bit (MSB) first, and each specifying a DNS RRTYPE that must be for a data RRTYPE as described in Section 3.1 of [RFC6895]. Individual values from the list (with unspecified index "x") are referred to as "QTx" in the following sections.
OPTION-DATA は、最上位ビット (MSB) が先頭となるネットワーク順の 2 オクテットの値のリストであり、[RFC6895] のセクション 3.1 で説明されているデータ RRTYPE でなければならない DNS RRTYPE をそれぞれ指定します。リストの個々の値 (未指定のインデックス "x" を持つ) は、次のセクションでは "QTx" と呼ばれます。
DNS clients implementing this specification MUST generate packets that conform to the server request parsing rules described in Section 3.3.
この仕様を実装する DNS クライアントは、セクション 3.3 で説明されているサーバー要求解析規則に準拠するパケットを生成しなければなりません (MUST)。
The choice of when a client implementation should attempt to coalesce queries for multiple QTYPEs using this method is implementation specific and not discussed further herein. However, careful considerations should be taken into account when coalescing queries on behalf of an application, if such a feature is not explicitly requested by the application. How an application interacts with an underlying name resolution library is internal to the implementation and is thus out of scope.
クライアント実装がこのメソッドを使用して複数の QTYPE のクエリの結合を試みるタイミングの選択は実装固有であり、ここではこれ以上説明しません。ただし、そのような機能がアプリケーションによって明示的に要求されていない場合、アプリケーションに代わってクエリを結合するときは、慎重に考慮する必要があります。アプリケーションが基礎となる名前解決ライブラリと対話する方法は実装の内部的なものであるため、範囲外です。
In addition to the error cases discussed in Section 7 of [RFC6891], the server MUST return a FORMERR response if the server receives:
[RFC6891] のセクション 7 で説明されているエラーケースに加えて、サーバーが以下を受信した場合、サーバーは FORMERR 応答を返さなければなりません (MUST)。
* An MQTYPE-Query option in any inbound DNS message with an OpCode other than QUERY (0).
* QUERY (0) 以外の OpCode を持つ受信 DNS メッセージの MQTYPE-Query オプション。
* An MQTYPE-Response option in any inbound DNS message.
* 受信 DNS メッセージの MQTYPE-Response オプション。
* More than one MQTYPE-Query option in a query.
* クエリ内の複数の MQTYPE-Query オプション。
* An MQTYPE-Query in a query that contains no primary question (i.e., QDCOUNT=0).
* 主な質問を含まないクエリ内の MQTYPE-Query (つまり、QDCOUNT=0)。
* An MQTYPE-Query option in a query where the primary question is a non-data RRTYPE (e.g., ANY, AXFR).
* 主な質問が非データ RRTYPE (ANY、AXFR など) であるクエリ内の MQTYPE-Query オプション。
* An MQTYPE-Query option with an empty QT list.
* 空の QT リストを含む MQTYPE-Query オプション。
* An invalid QTx (e.g., one corresponding to a Meta RRTYPE).
* 無効な QTx (例: Meta RRTYPE に対応する QTx)。
* A duplicate QTx (or one duplicating the primary QTYPE field) in a query.
* クエリ内の重複した QTx (またはプライマリ QTYPE フィールドを重複した QTx)。
A conforming server that receives an MQTYPE-Query option in a valid query MUST return an MQTYPE-Response option in its response, even if that response is truncated (TC=1). This is necessary to indicate that the server does support this extension. Refer to Section 3.3 for invalid queries.
有効なクエリで MQTYPE-Query オプションを受け取る適合サーバーは、たとえその応答が切り捨てられていたとしても (TC=1)、その応答で MQTYPE-Response オプションを返さなければなりません (MUST)。これは、サーバーがこの拡張機能をサポートしていることを示すために必要です。無効なクエリについてはセクション 3.3 を参照してください。
The server MUST first start constructing a response for the primary (QNAME, QCLASS, QTYPE) tuple specified in the Question section per the existing DNS sections. The RCODE and all other flags (such as AA or AD) MUST be determined at this time.
サーバーはまず、既存の DNS セクションに従って、Question セクションで指定されたプライマリ (QNAME、QCLASS、QTYPE) タプルに対する応答の構築を開始しなければなりません (MUST)。RCODE および他のすべてのフラグ (AA または AD など) はこの時点で決定する必要があります。
If this initial response results in truncation (TC=1), then the additional queries specified in the MQTYPE-Query option MUST NOT be processed.
この初期応答の結果が切り捨て (TC=1) になる場合、MQTYPE-Query オプションで指定された追加のクエリを処理してはなりません (MUST NOT)。
After the initial response is prepared, the server MUST attempt to combine the responses for individual (QNAME, QCLASS, QTx) combinations into the response for the first query. If a recursive server does not yet have those responses available, it MAY first make appropriate outbound queries to populate its caches.
初期応答が準備された後、サーバーは、個々の (QNAME、QCLASS、QTx) の組み合わせに対する応答を最初のクエリの応答に結合することを試行しなければなりません (MUST)。再帰的サーバーがそれらの応答をまだ利用できない場合、まず適切なアウトバウンドクエリを作成してキャッシュにデータを追加してもよい(MAY)。
For each individual combination, the server MUST evaluate the resulting RCODE and other flags and check that they all match the values generated from the primary query.
個々の組み合わせごとに、サーバーは結果の RCODE およびその他のフラグを評価し、それらがすべてプライマリ クエリから生成された値と一致することを確認しなければなりません (MUST)。
If any mismatch is detected, the mismatching additional response MUST NOT be included in the final combined response, and its QTx value MUST NOT be included in the MQTYPE-Response option's list. This might happen, for example, if the primary query resulted in a NOERROR response, but a QTx query resulted in a SERVFAIL. This could also happen if the primary response has AA=0, but a QTx response has AA=1, which might happen if the NS and DS records were both requested at the parent side of a zone cut.
不一致が検出された場合、不一致の追加応答を最終的な結合応答に含めてはなりません (MUST NOT)。また、その QTx 値を MQTYPE-Response オプションのリストに含めてはなりません (MUST NOT)。これは、たとえば、プライマリ クエリの結果が NOERROR 応答だったが、QTx クエリの結果が SERVFAIL だった場合に発生する可能性があります。これは、プライマリ応答が AA=0 であるのに、QTx 応答が AA=1 である場合にも発生する可能性があります。これは、NS レコードと DS レコードの両方がゾーン カットの親側で要求された場合に発生する可能性があります。
The server MUST attempt to combine the remaining individual RRs into the same sections in which they would have appeared in a standalone query (i.e., as if each combination had been "the question" per Section 4.1 of RFC 1035 [STD13]).
サーバーは、残りの個々の RR を、スタンドアロンのクエリに出現するのと同じセクションに結合することを試行しなければなりません (つまり、各組み合わせが RFC 1035 [STD13] のセクション 4.1 に従って「質問」であるかのように)。
The server MUST detect duplicate RRs and keep only a single copy of each RR in its respective section. Duplicates can occur, for example, in the Answer section if a CNAME chain is involved, or in the Authority section if multiple QTYPEs don't exist, etc. Note that RRs can be legitimately duplicated in different sections such as for the (SOA, TYPE12345) combination at a zone apex where TYPE12345 is not present.
サーバーは重複した RR を検出し、各 RR のコピーをそれぞれのセクションに 1 つだけ保持しなければなりません (MUST)。たとえば、CNAME チェーンが関係している場合は Answer セクションで、複数の QTYPE が存在しない場合は Authority セクションなどで重複が発生する可能性があります。TYPE12345 が存在しないゾーン頂点での (SOA、TYPE12345) の組み合わせなど、異なるセクションで RR が正当に複製される可能性があることに注意してください。
The handling of an MQTYPE-Query option MUST NOT itself trigger a truncated response. If response size (or other) limits do not allow all of the data obtained by querying for an additional QTx to be included in the final response in their entirety (i.e., as complete RRsets), then the server MUST NOT include the respective QTx in the MQTYPE-Response option's list and MAY stop processing further QTx combinations.
MQTYPE-Query オプションの処理自体が、切り捨てられた応答をトリガーしてはなりません (MUST NOT)。応答サイズ (またはその他) の制限により、追加の QTx のクエリによって取得されたデータのすべてを最終応答全体 (つまり、完全な RRset として) に含めることができない場合、サーバーはそれぞれの QTx を MQTYPE-Response オプションのリストに含めてはならず、それ以上の QTx の組み合わせの処理を停止してもよい(MAY)。
If all RRs for a single QTx combination fit into the message, then the server MUST include the respective QTx in the MQTYPE-Response option's list to indicate that the given query type was completely processed.
単一の QTx の組み合わせのすべての RR がメッセージに収まる場合、サーバーは、指定されたクエリ タイプが完全に処理されたことを示すために、MQTYPE-Response オプションのリストにそれぞれの QTx を含めなければなりません (MUST)。
Note that it is possible for the resulting MQTYPE-Response option to contain an empty list, but as described above, the option must still be returned.
結果の MQTYPE-Response オプションに空のリストが含まれる可能性がありますが、前述したように、オプションは返される必要があることに注意してください。
If the response to a query containing an MQTYPE-Query option does not contain an MQTYPE-Response option, or if it erroneously contains an MQTYPE-Query option, the client MUST treat the response as if this option is unsupported by the server and MUST process the primary response as if the MQTYPE-Query option had not been used.
MQTYPE-Query オプションを含むクエリへの応答に MQTYPE-Response オプションが含まれていない場合、または誤って MQTYPE-Query オプションが含まれている場合、クライアントはその応答を、このオプションがサーバーでサポートされていないものとして扱わなければなりません (MUST)。また、MQTYPE-Query オプションが使用されていないかのように主応答を処理しなければなりません (MUST)。
In the above case, or if the server generates a FORMERR response, the client MUST issue additional standalone queries (that is, without using the MQTYPE-Query option) for all QTYPEs for which an answer is still required.
上記の場合、またはサーバーが FORMERR 応答を生成する場合、クライアントは、応答が必要なすべての QTYPE に対して追加のスタンドアロン クエリを (つまり、MQTYPE-Query オプションを使用せずに) 発行しなければなりません (MUST)。
If the MQTYPE-Response option is present more than once or if a QTx value is duplicated (or duplicates the primary QTYPE field), the client MUST treat the answer as invalid (equivalent to FORMERR).
MQTYPE-Response オプションが複数回存在する場合、または QTx 値が重複している場合 (またはプライマリ QTYPE フィールドが重複している場合)、クライアントはその回答を無効なものとして扱わなければなりません (FORMERR と同等)。
The Question section and the list of types present in the MQTYPE-Response option indicates the list of (QNAME, QCLASS, QTYPEs) combinations that are completely answered and contained within the received response. The answers to all query combinations share the same RCODE and all other flags.
Question セクションと MQTYPE-Response オプションに存在するタイプのリストは、完全に回答され、受信した応答に含まれる (QNAME、QCLASS、QTYPE) の組み合わせのリストを示します。すべてのクエリの組み合わせに対する答えは、同じ RCODE と他のすべてのフラグを共有します。
All RRs required by existing DNS specifications are expected to be present in the respective sections of the DNS message, including proofs of nonexistence where required. The client MUST NOT rely on any particular order of RRs in the message sections.
既存の DNS 仕様で要求されるすべての RR は、必要に応じて存在しない証明を含め、DNS メッセージのそれぞれのセクションに存在することが期待されます。クライアントは、メッセージ セクション内の RR の特定の順序に依存してはなりません (MUST NOT)。
For the purposes of Section 5.4.1 of [RFC2181], any authoritative answers received MUST be ranked the same as the answer for the primary question.
[RFC2181] のセクション 5.4.1 の目的のため、受け取った信頼できる回答は、最初の質問に対する回答と同じにランク付けされなければなりません (MUST)。
Clients MUST take into account that individual RRs might originate from different DNS zones and that proofs of nonexistence might have been produced by different signers.
クライアントは、個々の RR が異なる DNS ゾーンから発信されている可能性があること、および存在しない証明が異なる署名者によって作成された可能性があることを考慮しなければなりません (MUST)。
Absence of QTx values that were requested by the client but are not present in the MQTYPE-Response option indicates that:
クライアントによって要求された QTx 値が MQTYPE-Response オプションに存在しないことは、次のことを示します。
* (for responses from recursive servers) the server does not have any records for that QTx value in cache, and/or
* (再帰サーバーからの応答の場合) サーバーのキャッシュ内にその QTx 値のレコードが存在しない、および/または
* the individual responses could not be combined into one message because of RCODE or other flag mismatches, and/or
* RCODE またはその他のフラグの不一致のため、個々の応答を 1 つのメッセージに結合できなかった、および/または
* the server was unwilling to process the request (for example, because a limit was exceeded), and/or
* サーバーがリクエストを処理する意思がなかった（制限を超えたなどの理由で）、および/または
* the response size limit would be exceeded.
* 応答サイズの制限を超えてしまう可能性があります。
The client MUST subsequently initiate separate standalone queries for all QTx values for which an answer is still required.
クライアントはその後、応答が必要なすべての QTx 値に対して個別のスタンドアロン クエリを開始しなければなりません (MUST)。
The method documented here does not change any of the security properties of the DNS protocol itself.
ここに記載されている方法では、DNS プロトコル自体のセキュリティ プロパティは変更されません。
However, it should be noted that this method does increase the potential amplification factor when the DNS protocol is used as a vector for a denial-of-service attack. A further risk is being able to maliciously cause recursive servers to perform large amounts of additional work.
ただし、この方法では、DNS プロトコルがサービス拒否攻撃のベクトルとして使用される場合、潜在的な増幅率が増加することに注意してください。さらなるリスクは、再帰的サーバーに悪意を持って大量の追加作業を実行させる可能性があることです。
Implementors SHOULD therefore allow operators to configure limits on the number of QTx values specified and/or the resulting response size. The recommended values of those limits will depend on the environment in which this specification is used. In public DNS, it is expected that a limit of four QTx values would be appropriate, but when used with DNS-SD or within private networks, higher limits would be acceptable.
したがって、実装者は、指定された QTx 値の数および/または結果の応答サイズに対する制限をオペレーターが設定できるようにすべきです (SHOULD)。これらの制限の推奨値は、この仕様が使用される環境によって異なります。パブリック DNS では、4 つの QTx 値の制限が適切であることが予想されますが、DNS-SD で使用する場合やプライベート ネットワーク内で使用する場合は、より高い制限も許容されます。
IANA has assigned the following values in the "DNS EDNS0 Option Codes (OPT)" registry within the "Domain Name System (DNS) Parameters" registry group:
IANA は、「ドメイン ネーム システム (DNS) パラメーター」レジストリ グループ内の「DNS EDNS0 オプション コード (OPT)」レジストリに次の値を割り当てました。
+=======+=================+==========+===========+
| Value | Name | Status | Reference |
+=======+=================+==========+===========+
| 20 | MQTYPE-Query | Optional | RFC 10029 |
+-------+-----------------+----------+-----------+
| 21 | MQTYPE-Response | Optional | RFC 10029 |
+-------+-----------------+----------+-----------+
Table 1: MQTYPE EDNS Option Numbers
表 1: MQTYPE EDNS オプション番号
[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>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[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>.
[RFC9619] Bellis, R. and J. Abley, "In the DNS, QDCOUNT Is (Usually)
One", RFC 9619, DOI 10.17487/RFC9619, July 2024,
<https://www.rfc-editor.org/info/rfc9619>.
[STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following:
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt,
"Providing Minimal-Sized Responses to DNS Queries That
Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January
2019, <https://www.rfc-editor.org/info/rfc8482>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
The examples below are shown as what might be reported by the Internet Systems Consortium (ISC) Dig utility. For the purposes of brevity, irrelevant content is omitted.
以下の例は、Internet Systems Consortium (ISC) Dig ユーティリティによって報告される可能性のあるものとして示されています。簡潔にするために、関係のない内容は省略されています。
In this example, a stub resolver has requested the A record for www.example.com, along with an MQTYPE-Query option requesting AAAA and HTTPS records. The stub resolver has also set the DO bit, indicating DNSSEC support.
この例では、スタブリゾルバーは、AAAA レコードと HTTPS レコードを要求する MQTYPE-Query オプションとともに、www.example.com の A レコードを要求しています。スタブリゾルバは、DNSSEC サポートを示す DO ビットも設定しています。
The presence of the HTTPS QTYPE in the MQTYPE-Response option of the response coupled with its absence from the Answer section indicates that the recursive server currently holds no data for this QTYPE. The corresponding type fields in the NSEC3 record further provide a cryptographic proof of nonexistence for the HTTPS QTYPE, and the SOA record also indicates a "negative answer".
応答の MQTYPE-Response オプションに HTTPS QTYPE が存在することと、Answer セクションに HTTPS QTYPE が存在しないことは、再帰サーバーが現在この QTYPE のデータを保持していないことを示しています。NSEC3 レコード内の対応するタイプ フィールドは、HTTPS QTYPE が存在しないことの暗号学的証明をさらに提供し、SOA レコードも「否定的な回答」を示します。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11111
;; flags: qr rd ra ad
;; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; MQTYPE-Response: AAAA HTTPS
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 2849 IN A 192.0.2.1
www.example.com. 2849 IN RRSIG A [...]
www.example.com. 3552 IN AAAA 3fff::1234
www.example.com. 3552 IN RRSIG AAAA [...]
;; AUTHORITY SECTION:
example.com. 2830 IN SOA ns.example.com. [...]
example.com. 2830 IN RRSIG SOA 13 2 [...]
[...].example.com. 2830 IN NSEC3 [...] A TXT AAAA RRSIG
[...].example.com. 2830 IN RRSIG NSEC3 [...]
Figure 3: A, AAAA, and HTTPS
図 3: A、AAAA、および HTTPS
In this similar example, the primary QTYPE is for DS, and the MQTYPE-Query field only contains DNSKEY.
この同様の例では、プライマリ QTYPE は DS 用であり、MQTYPE-Query フィールドには DNSKEY のみが含まれています。
Both the DS and DNSKEY records are returned, along with their corresponding RRSIG records.
DS レコードと DNSKEY レコードの両方が、対応する RRSIG レコードとともに返されます。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33333
;; flags: qr rd ra ad
;; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; MQTYPE-Response: DNSKEY
;; QUESTION SECTION:
;example.com. IN DS
;; ANSWER SECTION:
example.com. 625 IN DNSKEY 256 3 13 [...]
example.com. 625 IN DNSKEY 257 3 13 [...]
example.com. 625 IN RRSIG DNSKEY [...] example.com. [...]
example.com. 86185 IN DS 370 13 2 [...]
example.com. 86185 IN RRSIG DS [...] com. [...]
Figure 4: Stub DS and DNSKEY
図 4: スタブ DS と DNSKEY
In this instance, a recursive resolver is sending a DS record query to the parent zone's authoritative server and simultaneously requesting the NS records for the zone.
この例では、再帰的リゾルバーが親ゾーンの権威サーバーに DS レコード クエリを送信し、同時にゾーンの NS レコードを要求します。
Since the DS record response is marked as authoritative (AA = 1), but the NS record data on the parent side of a zone cut is not authoritative (AA = 0), the server is unable to merge the responses, and the NS QTYPE is omitted from the MQTYPE-Response field.
DS レコード応答には権限がある (AA = 1) とマークされていますが、ゾーン カットの親側の NS レコード データには権限がない (AA = 0) ため、サーバーは応答をマージできず、NS QTYPE が MQTYPE 応答フィールドから省略されます。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33333
;; flags: qr aa
;; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; MQTYPE-Response: [empty]
;; QUESTION SECTION:
;example.com. IN DS
;; ANSWER SECTION:
example.com. 86185 IN DS 370 13 2 [...]
example.com. 86185 IN RRSIG DS [...] com. [...]
Figure 5: Recursive DS and NS
図 5: 再帰的 DS と NS
The author wishes to thank the following for their feedback and reviews during the initial development of this document: Michael Graff, Olafur Gudmundsson, Matthijs Mekking, and Paul Vixie.
著者は、この文書の初期開発中にフィードバックとレビューをしてくださった次の方々に感謝の意を表します: Michael Graff、Olafur Gudmundsson、Matthijs Mekking、および Paul Vixie。
In addition, the author wishes to thank the following for subsequent reviews during discussion in the DNSSD Working Group: Chris Box, Stuart Cheshire, Esko Dijk, Ted Lemon, David Schinazi, and Petr Spacek.
さらに、著者は、DNSSD ワーキング グループでの議論中にその後のレビューをしていただいた次の方々に感謝したいと思います: Chris Box、Stuart Cheshire、Esko Dijk、Ted Lemon、David Schinazi、Petr Spacek。
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