[要約] RFC 7901は、DNSでのCHAINクエリリクエストに関する仕様を提供しています。このRFCの目的は、DNSセキュリティ拡張の一環として、CHAINクエリを使用してDNSチェーンの情報を取得する方法を定義することです。
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7901 Red Hat
Category: Experimental June 2016
ISSN: 2070-1721
CHAIN Query Requests in DNS
DNSのチェーンクエリ要求
Abstract
概要
This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP-verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.
このドキュメントでは、転送リゾルバを使用して単一のクエリを送信するように構成されたセキュリティ対応の検証リゾルバが使用できるEDNS0拡張を定義し、通常のクエリの回答とともに完全な検証パスを要求します。クエリの削減により、潜在的にレイテンシが低下し、一度に複数のクエリを送信する必要性が減少します。この拡張は、EDNS-COOKIEでのTCPやUDPなどのソースIP検証済みトランスポートの使用を義務付けているため、増幅攻撃で悪用されることはありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 http://www.rfc-editor.org/info/rfc7901.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7901で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 6
5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6
5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 7
6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8
6.2. NS Record Considerations . . . . . . . . . . . . . . . . 8
6.3. Session Management . . . . . . . . . . . . . . . . . . . 9
6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9
6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Additional Work and Bandwidth . . . . . . . . . . . . . . 10
7.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. CHAIN Query for "www.example.com" . . . . . . . . . . . . 10
8.2. Out-of-Path Query for "example.com" . . . . . . . . . . . 12
8.3. Nonexistent Data . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. EDNS0 Option Code for CHAIN . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
Traditionally, a DNS client operates in stub mode. For each DNS question the DNS client needs to resolve, it sends a single query to an upstream recursive resolver to obtain a single DNS answer. When DNSSEC [RFC4033] is deployed on such DNS clients, validation requires that the client obtain all the intermediate information from the DNS root down to the queried-for host name, so it can perform DNSSEC validation on the complete chain of trust.
従来、DNSクライアントはスタブモードで動作していました。 DNSクライアントは、DNSクライアントが解決する必要がある各DNS質問に対して、単一のクエリを上流の再帰リゾルバに送信して、単一のDNS回答を取得します。このようなDNSクライアントにDNSSEC [RFC4033]が配備されている場合、検証では、クライアントがDNSルートからクエリ対象のホスト名までのすべての中間情報を取得する必要があるため、信頼の完全なチェーンでDNSSEC検証を実行できます。
Currently, applications send out many UDP requests concurrently. This requires more resources on the DNS client with respect to state (CPU, memory, battery) and bandwidth. There is also no guarantee that the initial set of UDP questions will result in all the records required for DNSSEC validation. More round trips could be required depending on the resulting DNS answers. This especially affects high-latency links.
現在、アプリケーションは多数のUDP要求を同時に送信しています。これには、状態（CPU、メモリ、バッテリー）と帯域幅に関して、DNSクライアントでより多くのリソースが必要です。また、UDPの質問の最初のセットがDNSSEC検証に必要なすべてのレコードになるという保証もありません。結果のDNS回答によっては、さらに往復が必要になる場合があります。これは特に高遅延リンクに影響します。
This document specifies an EDNS0 extension that allows a validating resolver running as a forwarding resolver to open a TCP connection to another resolver and request a DNS chain answer using one DNS query/ answer pair. This reduces the number of round trips to two. If combined with long-lived TCP or [RFC7828], there is only one round trip. While the upstream resolver still needs to perform all the individual queries required for the complete answer, it usually has a much bigger cache and does not experience significant slowdown from last-mile latency.
このドキュメントでは、転送リゾルバーとして実行されている検証リゾルバーが別のリゾルバーへのTCP接続を開き、1つのDNSクエリ/応答ペアを使用してDNSチェーン応答を要求できるようにするEDNS0拡張を指定します。これにより、往復回数が2回に減ります。長期間のTCPまたは[RFC7828]と組み合わせると、ラウンドトリップは1つだけになります。アップストリームリゾルバーは完全な回答に必要な個々のクエリをすべて実行する必要がありますが、通常はキャッシュがはるかに大きく、ラストマイルレイテンシによる大幅な速度低下は発生しません。
This EDNS0 extension allows the forwarding resolver to indicate which part of the DNS hierarchy it already contains in its cache. This reduces the amount of data required to be transferred and reduces the work the upstream recursive resolver has to perform.
このEDNS0拡張機能により、転送リゾルバーは、DNS階層のどの部分がキャッシュに既に含まれているかを示すことができます。これにより、転送する必要のあるデータの量が減り、上流の再帰リゾルバーが実行する必要のある作業が減ります。
This EDNS0 extension is only intended to be sent by forwarding resolvers to recursive resolvers. It MUST be ignored by authoritative servers.
このEDNS0拡張機能は、転送リゾルバーから再帰リゾルバーに送信されることのみを目的としています。権限のあるサーバーでは無視する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The DNS terminology used in this document is that of [RFC7719]. Additionally, the following terms are used:
このドキュメントで使用されているDNSの用語は、[RFC7719]の用語です。さらに、次の用語が使用されます。
Forwarding Resolver: A nameserver that does not do iterative resolution itself; instead, it passes that responsibility to another recursive resolver, called a "forwarder" in [RFC2308], Section 1.
Forwarding Resolver：反復解決自体を行わないネームサーバー。代わりに、[RFC2308]のセクション1で「フォワーダー」と呼ばれる別の再帰リゾルバーにその責任を渡します。
Recursive Resolver: A nameserver that is responsible for resolving domain names for clients by following the domain's delegation chain, starting at the root. Recursive resolvers frequently use caches to be able to respond to client queries quickly, as described in [RFC1035], Section 7.
再帰リゾルバー：ルートから開始して、ドメインの委任チェーンに従ってクライアントのドメイン名を解決するネームサーバー。 [RFC1035]のセクション7で説明されているように、再帰リゾルバは頻繁にキャッシュを使用してクライアントのクエリにすばやく応答できるようにします。
Validating Resolver: A recursive nameserver that also performs DNSSEC [RFC4033] validation. Also known as "security-aware resolver".
リゾルバーの検証：DNSSEC [RFC4033]検証も実行する再帰的なネームサーバー。 「セキュリティ対応リゾルバ」とも呼ばれます。
When DNSSEC is deployed on a host, it can no longer delegate all DNS work to the upstream recursive resolver. Obtaining just the DNS answer itself is not enough to validate that answer using DNSSEC. For DNSSEC validation, the DNS client requires a locally running validating resolver, so it can confirm DNSSEC validation of all intermediary DNS answers. It can configure itself as a forwarding resolver if it obtains the IP addresses of one or more recursive resolvers that are available or as a stand-alone recursive resolver if no functional recursive resolvers were obtained. Generating the required queries for validation adds a significant delay in answering the DNS question of the locally running application. The application must wait while the resolver validates all intermediate answers. Each round trip adds to the total time waiting on DNS resolution with validation to complete. This makes DNSSEC resolving impractical for devices on networks with a high latency.
DNSSECがホストにデプロイされると、すべてのDNS作業を上流の再帰リゾルバーに委任できなくなります。 DNSSECを使用してその回答を検証するには、DNS回答自体を取得するだけでは不十分です。 DNSSEC検証の場合、DNSクライアントはローカルで実行される検証リゾルバーを必要とするため、すべての中間DNS回答のDNSSEC検証を確認できます。使用可能な1つ以上の再帰リゾルバーのIPアドレスを取得する場合は、自身を転送リゾルバーとして構成し、機能する再帰リゾルバーを取得しない場合は、スタンドアロンの再帰リゾルバーとして構成できます。検証に必要なクエリを生成すると、ローカルで実行されているアプリケーションのDNS質問への回答に大幅な遅延が追加されます。アプリケーションは、リゾルバーがすべての中間回答を検証するまで待機する必要があります。往復ごとに、検証が完了するまでのDNS解決を待機する合計時間が長くなります。これにより、待ち時間が長いネットワーク上のデバイスに対してDNSSEC解決が非現実的になります。
This document defines the CHAIN option that allows the resolver to request all intermediate DNS data it requires to resolve and validate a particular DNS answer in a single round trip. The resolver could be part of the application or a recursive resolver running on the host.
このドキュメントでは、特定のDNS回答を1回のラウンドトリップで解決および検証するために必要なすべての中間DNSデータをリゾルバーが要求できるようにするCHAINオプションを定義します。リゾルバーは、アプリケーションの一部である場合と、ホストで実行されている再帰リゾルバーである場合があります。
Servers answering with CHAIN data should ensure that the peer's IP address is not a spoofed source IP address. See Section 7. This prevents DNS amplification attacks.
CHAINデータで応答するサーバーは、ピアのIPアドレスが偽装されたソースIPアドレスではないことを確認する必要があります。セクション7を参照してください。これにより、DNS増幅攻撃が防止されます。
Applications that support CHAIN internally can perform validation without requiring the host to run a recursive resolver. This is particularly useful for virtual servers in a cloud or container-based deployment where it is undesirable to run a recursive resolver per virtual machine.
内部でCHAINをサポートするアプリケーションは、ホストが再帰リゾルバーを実行する必要なく、検証を実行できます。これは、仮想マシンごとに再帰リゾルバーを実行することが望ましくない、クラウドまたはコンテナーベースのデプロイメントの仮想サーバーに特に役立ちます。
The format of this option is described in Section 4.
このオプションの形式については、セクション4で説明します。
As described in Section 5.4, a recursive resolver can use this EDNS0 option to include additional data required by the resolver in the Authority Section of the DNS answer packet. The Answer Section remains unchanged from a traditional DNS answer and contains the answer and related DNSSEC entries.
セクション5.4で説明されているように、再帰リゾルバーはこのEDNS0オプションを使用して、リゾルバーが必要とする追加データをDNS応答パケットの権限セクションに含めることができます。回答セクションは、従来のDNS回答から変更されておらず、回答と関連するDNSSECエントリが含まれています。
An empty CHAIN EDNS0 option MAY be sent over any transport as a discovery method. A DNS server receiving such an empty CHAIN option SHOULD add an empty CHAIN option in its answer to indicate that it supports the CHAIN option.
空のCHAIN EDNS0オプションは、ディスカバリー方式としてトランスポートを介して送信される場合があります。そのような空のCHAINオプションを受信するDNSサーバーは、その回答に空のCHAINオプションを追加して、CHAINオプションをサポートすることを示す必要があります（SHOULD）。
The mechanisms provided by CHAIN raise various security concerns related to the additional work, bandwidth, amplification attacks, and privacy issues with the cache. These concerns are described in Section 7.
CHAINによって提供されるメカニズムは、追加の作業、帯域幅、増幅攻撃、およびキャッシュに関するプライバシーの問題に関連するさまざまなセキュリティ上の懸念を引き起こします。これらの懸念については、セクション7で説明します。
This document uses an EDNS0 option [RFC6891] to include client IP information in DNS messages. The option is structured as follows:
このドキュメントでは、DNSメッセージにクライアントIP情報を含めるためにEDNS0オプション[RFC6891]を使用しています。オプションは次のように構成されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
~ Closest Trust Point (FQDN) ~
+---------------------------------------------------------------+
o OPTION-CODE, 2 octets, for CHAIN is 13.
o OPTION-CODE、2オクテット、CHAINは13です。
o OPTION-LENGTH, 2 octets, contains the length of the payload (everything after Option-length) in octets.
o OPTION-LENGTH、2オクテットには、ペイロードの長さ（オプション長の後のすべて）がオクテットで含まれます。
o Closest trust point, a variable-length Fully-Qualified Domain Name (FQDN) in DNS wire format of the requested start point of the chain. This entry is the "lowest" known entry in the DNS chain known by the recursive server seeking a CHAIN answer for which it has a validated Delegation Signer (DS) and DNSKEY record. The endpoint of the chain is obtained from the DNS Query Section itself. No DNS name compression is allowed for this value.
o最も近いトラストポイント、チェーンの要求された開始ポイントのDNSワイヤー形式の可変長完全修飾ドメイン名（FQDN）。このエントリは、検証済みの委任署名者（DS）とDNSKEYレコードを持つチェーン回答を探している再帰サーバーによって認識されるDNSチェーンの「最も低い」既知のエントリです。チェーンのエンドポイントは、DNSクエリセクション自体から取得されます。この値にDNS名の圧縮は許可されていません。
A forwarding resolver may include a zero-length CHAIN option in a regular query over any transport to discover the DNS server capability for CHAIN. Recursive resolvers that support and are willing to accept CHAIN queries over source IP verified transport respond to a zero-length CHAIN received by including a zero-length CHAIN option in the answer. If not already using a source-IP-verified transport, the forwarding resolver MAY then switch to a source-IP-verified transport and start sending queries with the CHAIN option to request a CHAIN response from the recursive resolver. Examples of source-IP-verified transports are the three-way TCP handshake and UDP with DNS cookies [RFC7873].
転送リゾルバは、CHAINのDNSサーバー機能を検出するために、トランスポートを介した通常のクエリに長さ0のCHAINオプションを含めることができます。送信元IP検証済みトランスポートを介したCHAINクエリをサポートし、受け入れようとする再帰リゾルバーは、応答に長さゼロのチェーンオプションを含めることにより、長さゼロのチェーンに応答します。まだソースIP検証済みトランスポートを使用していない場合、転送リゾルバーはソースIP検証済みトランスポートに切り替え、CHAINオプションを指定してクエリの送信を開始し、再帰リゾルバーからのCHAIN応答を要求できます。ソースIPで検証されたトランスポートの例は、3方向のTCPハンドシェイクおよびDNS Cookieを使用したUDP [RFC7873]です。
In this option value, the forwarding resolver sets the closest trust point in the chain -- furthest from the root -- that it already has a DNSSEC-validated (secure or not) answer for in its cache. The upstream recursive resolver does not need to include any part of the chain from the root down to this option's FQDN. A complete example is described in Section 8.1.
このオプション値では、転送リゾルバは、ルート内で最も遠い、チェーン内の最も近いトラストポイントを設定します。これは、DNSSECで検証された（安全であるかどうかにかかわらず）回答がキャッシュに既にあることを示します。アップストリームの再帰リゾルバーは、ルートからこのオプションのFQDNまでのチェーンの一部を含める必要はありません。完全な例については、セクション8.1で説明します。
The CHAIN option should generally be sent by system forwarding resolvers and resolvers within an application that also performs DNSSEC validation.
CHAINオプションは、通常、システム転送リゾルバーと、DNSSEC検証も実行するアプリケーション内のリゾルバーによって送信されます。
When CHAIN is available, the downstream recursive resolver can adjust its query strategy based on the desired queries and its cache contents.
CHAINが使用可能な場合、ダウンストリームの再帰リゾルバーは、目的のクエリとキャッシュの内容に基づいてクエリ戦略を調整できます。
A forwarding resolver can request the CHAIN option with every outgoing DNS query. However, it is RECOMMENDED that forwarding resolvers remember which upstream recursive resolvers did not return the option (and additional data) with their response. The forwarding resolver SHOULD fall back to regular DNS for subsequent queries to those recursive resolvers. It MAY switch to another recursive resolver that does support the CHAIN option or try again later to see if the server has become less loaded and is now willing to answer with CHAIN queries. A fallback strategy similar to that described in
転送リゾルバは、すべての発信DNSクエリでCHAINオプションを要求できます。ただし、転送リゾルバーは、どの上流再帰リゾルバーがオプション（および追加データ）を応答で返さなかったかを記憶することをお勧めします。転送リゾルバは、それらの再帰リゾルバへの後続のクエリのために通常のDNSにフォールバックする必要があります（SHOULD）。それは、CHAINオプションをサポートする別の再帰リゾルバーに切り替えるか、サーバーが負荷が低くなり、CHAINクエリで応答する準備ができているかどうかを確認するために後で再試行できます。で説明されているものと同様のフォールバック戦略
[RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent interference due to non-clean paths.
[RFC6891]、セクション6.2.2を使用して、クリーンでないパスによる永続的な干渉を回避する必要があります。
When a query containing a non-zero CHAIN option is received from a forwarding resolver, the upstream recursive resolver supporting CHAIN MAY respond by confirming that it is returning a CHAIN. To do so, it MUST set the CHAIN option to the lowest trust point sent as part of the chain, with its corresponding OPTION-LENGTH. It extends the Authority Section in the DNS answer packet with the DNS RRsets required for validating the answer. The added DNS RRsets start with the first chain element below the received closest trust point up to and including the NS and DS RRsets that represent the zone cut (authoritative servers) of the QNAME. The added RRsets MAY be added in matching hierarchical order, but a DNS client MUST NOT depend on the order of the added RRsets for validation. The actual DNS answer to the question in the Query Section is placed in the DNS Answer Section identical to the traditional DNS answer. All required DNSSEC-related records must be added to their appropriate sections. This includes records required for proof of nonexistence of regular and/or wildcard records, such as NextSECure (NSEC) or NSEC3 records.
フォワーディングリゾルバーからゼロ以外のCHAINオプションを含むクエリを受信すると、CHAINをサポートする上流の再帰リゾルバーは、CHAINを返していることを確認して応答する場合があります。そのためには、CHAINオプションを、対応するOPTION-LENGTHとともに、チェーンの一部として送信される最低のトラストポイントに設定する必要があります。これは、DNS応答パケットの権限セクションを拡張して、応答の検証に必要なDNS RRsetを設定します。追加されたDNS RRsetは、QNAMEのゾーンカット（権限のあるサーバー）を表すNSおよびDS RRsetまでの、受信した最も近いトラストポイントの下の最初のチェーン要素から始まります。追加されたRRsetは、一致する階層順に追加される場合がありますが、DNSクライアントは、検証のために追加されたRRsetの順序に依存してはなりません（MUST NOT）。クエリセクションの質問に対する実際のDNS回答は、従来のDNS回答と同じDNS回答セクションに配置されます。必要なすべてのDNSSEC関連レコードを適切なセクションに追加する必要があります。これには、NextSECure（NSEC）またはNSEC3レコードなど、通常のレコードやワイルドカードレコードが存在しないことの証明に必要なレコードが含まれます。
Recursive resolvers that have not implemented or enabled support for the CHAIN option, or are otherwise unwilling to perform the additional work for a CHAIN query due to workload, may safely ignore the option in the incoming queries. Such a server MUST NOT include a CHAIN option when sending DNS answer replies back, thus indicating it is not able or willing to support CHAIN queries at this time.
CHAINオプションのサポートを実装または有効にしていない、またはワークロードが原因でCHAINクエリの追加作業を実行したくない再帰リゾルバーは、着信クエリのオプションを安全に無視できます。このようなサーバーは、DNS回答の返信を送信するときにCHAINオプションを含めてはなりません（MUST NOT）。つまり、現時点ではCHAINクエリをサポートできない、またはサポートする意思がないことを示しています。
Requests with wrongly formatted options (i.e., bogus FQDN) MUST be rejected; a FORMERR response must be returned to the sender, as described by [RFC6891].
誤ってフォーマットされたオプション（つまり、偽のFQDN）を含むリクエストは拒否する必要があります。 [RFC6891]で説明されているように、FORMERR応答は送信者に返される必要があります。
Requests resulting in chains that the receiving resolver is unwilling to serve can be rejected by answering the query as a regular DNS reply but with an empty CHAIN payload. Replying with an empty CHAIN can be used for chains that would be too big or for chains that would reveal too much information considered private.
受信リゾルバがサービスを提供することを望まないチェーンをもたらす要求は、通常のDNS応答としてクエリに応答することにより拒否できますが、CHAINペイロードは空です。空のチェーンで返信すると、大きすぎるチェーンや、プライベートと見なされる情報が多すぎるチェーンに使用できます。
At any time, a recursive resolver that has determined that it is running low on resources can refuse CHAIN queries by replying with a regular DNS reply with an empty CHAIN payload.
リソースが不足していると判断した再帰リゾルバは、空のCHAINペイロードを含む通常のDNS応答で応答することにより、いつでもCHAINクエリを拒否できます。
If a CHAIN answer would be bigger than the recursive resolver is willing to serve, it SHOULD send a partial chain starting with the data closest to the top of the chain. The client MAY resend the query with an updated closest trust point until it has received the full chain. The CHAIN response will contain the lowest closest trust point that was included in the CHAIN answer.
チェーンの回答が再帰リゾルバが提供する用意があるよりも大きい場合、チェーンの最上部に最も近いデータで始まる部分チェーンを送信する必要があります。クライアントは、完全なチェーンを受信するまで、更新された最も近いトラストポイントを使用してクエリを再送信できます。 CHAIN応答には、CHAIN回答に含まれていた最も近い最も近いトラストポイントが含まれます。
If the DNS request results in a CNAME or DNAME for the Answer Section, the recursive resolver MUST return these records in the Answer Section similar to regular DNS processing. The CNAME or DNAME target MAY be placed in the Additional Section only if all supporting records for DNSSEC validation of the CNAME or DNAME target are also added to the Authority Section.
DNS要求が回答セクションのCNAMEまたはDNAMEになる場合、再帰リゾルバーは通常のDNS処理と同様にこれらのレコードを回答セクションに返さなければなりません（MUST）。 CNAMEまたはDNAMEターゲットは、CNAMEまたはDNAMEターゲットのDNSSEC検証のすべてのサポートレコードも権限セクションに追加されている場合にのみ、追加セクションに配置できます（MAY）。
The response from a recursive resolver to a resolver MUST NOT contain the CHAIN option if none was present in the resolver's original request.
再帰リゾルバーからリゾルバーへの応答には、リゾルバーの元の要求にCHAINオプションが含まれていない場合は、CHAINオプションを含めてはなりません（MUST NOT）。
A DNS query that contains the CHAIN option MUST also have the "DNSSEC OK" (DO) bit set. If this bit is not set, or if the "Checking Disabled" (CD) bit is set, the CHAIN option received MUST be ignored.
CHAINオプションを含むDNSクエリには、「DNSSEC OK」（DO）ビットも設定する必要があります。このビットが設定されていない場合、または "Checking Disabled"（CD）ビットが設定されている場合は、受け取ったCHAINオプションを無視する必要があります。
The presence or absence of an OPT resource record containing a CHAIN option in a DNS query does not change the usage of those resource records and mechanisms used to provide data origin authentication and data integrity to the DNS, as described in [RFC4033], [RFC4034], and [RFC4035].
[RFC4033]、[RFC4034]で説明されているように、DNSクエリにCHAINオプションを含むOPTリソースレコードが存在してもしなくても、DNSにデータ発信元認証とデータ整合性を提供するために使用されるリソースレコードとメカニズムの使用法は変わりません]、[RFC4035]。
CHAIN responses SHOULD include the authoritative NS RRset with its RRSIG records required for validation. It MUST NOT include the NS RRset from the parent zone, as this RRset is not signed. If the size of the answer is an important factor, the NS RRset MAY be omitted.
チェーン応答には、検証に必要なRRSIGレコードを含む信頼できるNS RRsetを含める必要があります（SHOULD）。このRRsetは署名されていないため、親ゾーンからのNS RRsetを含めることはできません。回答のサイズが重要な要素である場合、NS RRsetは省略される場合があります。
When a DNSSEC chain is supplied via CHAIN, the forwarding resolver is no longer required to use the NS RRset, as it can construct the validation path via the DNSKEY and DS RRsets without using the NS RRset. However, the forwarding resolver might be forced to switch from forwarding resolver mode to recursive resolver mode due to a network topology change. In recursive resolver mode, the NS RRsets are needed to find and query authoritative servers directly. It is RECOMMENDED that the DNS forwarding resolver populate its cache with this information to avoid requiring future queries to obtain any missing NS records. Therefore, CHAIN responses MUST include the NS RRset from the child zone, including the RRSIG records required for validation.
DNSSECチェーンがCHAINを介して提供される場合、転送リゾルバーはNS RRsetを使用せずにDNSKEYおよびDS RRsetを介して検証パスを構築できるため、NS RRsetを使用する必要はありません。ただし、ネットワークトポロジの変更により、転送リゾルバは転送リゾルバモードから再帰リゾルバモードに強制的に切り替えられる場合があります。再帰リゾルバーモードでは、権限のあるサーバーを直接検索して照会するためにNS RRsetが必要です。欠落しているNSレコードを取得するために今後のクエリを要求しないように、DNS転送リゾルバーがこの情報をキャッシュに入力することをお勧めします。したがって、CHAIN応答には、検証に必要なRRSIGレコードを含め、子ゾーンからのNS RRsetを含める必要があります。
The use of TCP keepalive [RFC7828] on DNS TCP sessions is RECOMMENDED; thus, TCP sessions should not immediately be closed after the DNS answer to the first query is received.
DNS TCPセッションでのTCPキープアライブ[RFC7828]の使用は推奨されています。したがって、最初のクエリに対するDNS応答を受信した後、TCPセッションをすぐに閉じないでください。
Both DNS clients and servers are subject to resource constraints that will limit the extent to which CHAIN queries can be executed. Effective limits for the number of active sessions that can be maintained on individual clients and servers should be established either as configuration options or by interrogation of process limits imposed by the operating system.
DNSクライアントとサーバーはどちらも、CHAINクエリを実行できる範囲を制限するリソースの制約を受けます。個々のクライアントおよびサーバーで維持できるアクティブなセッション数の有効な制限は、構成オプションとして、またはオペレーティングシステムによって課されるプロセス制限の問い合わせによって確立する必要があります。
In the event that there is greater demand for CHAIN queries than can be accommodated, DNS servers may stop advertising the CHAIN option in successive DNS messages. This allows, for example, clients with other candidate servers to query to establish new sessions with different servers in expectation that those servers might still allow CHAIN queries.
対処できるよりも大きなCHAINクエリの需要がある場合、DNSサーバーは、後続のDNSメッセージでCHAINオプションのアドバタイズを停止することがあります。これにより、たとえば、他の候補サーバーを持つクライアントがクエリを実行して、それらのサーバーが引き続きCHAINクエリを許可することを想定して、異なるサーバーとの新しいセッションを確立できます。
If a CHAIN answer would intersect with a negative trust anchor [RFC7646], a partial CHAIN up to the node above the negative trust anchor should be returned.
CHAINの回答が負のトラストアンカーと交差する場合[RFC7646]、負のトラストアンカーの上のノードまでの部分的なCHAINが返されます。
Recursive resolvers of various types are commonly deployed using anycast [RFC4786].
さまざまなタイプの再帰リゾルバは、一般にエニーキャスト[RFC4786]を使用して配備されます。
Successive DNS transactions between a client and server using UDP transport may involve responses generated by different anycast nodes, and the use of anycast in the implementation of a DNS server is effectively undetectable by the client. The CHAIN option SHOULD NOT be included in responses using UDP transport from servers provisioned using anycast unless all anycast server nodes are capable of processing the CHAIN option.
UDPトランスポートを使用したクライアントとサーバー間の連続したDNSトランザクションには、さまざまなエニーキャストノードによって生成された応答が含まれる場合があり、DNSサーバーの実装でのエニーキャストの使用は、クライアントによって事実上検出されません。すべてのエニーキャストサーバーノードがCHAINオプションを処理できる場合を除き、エニーキャストを使用してプロビジョニングされたサーバーからのUDPトランスポートを使用した応答には、CHAINオプションを含めないでください。
Since DNS queries using CHAIN may result in longer TCP sessions, network topology changes may disrupt them more frequently. Anycast servers MAY make use of Multipath TCP [RFC6824] to anchor the server side of the TCP connection to an unambiguously unicast address in order to avoid disruption due to topology changes.
CHAINを使用したDNSクエリはTCPセッションを長くする可能性があるため、ネットワークトポロジの変更により、頻繁に混乱する可能性があります。エニーキャストサーバーは、トポロジ変更による中断を回避するために、マルチパスTCP [RFC6824]を利用して、TCP接続のサーバー側を明確にユニキャストアドレスに固定することができます。
Producing CHAIN answers incurs additional load and bandwidth on the recursive resolver. At any time, a recursive resolver may decide to no longer answer with CHAIN answers and fall back to traditional DNS answers.
チェーン応答を生成すると、再帰リゾルバに追加の負荷と帯域幅がかかります。いつでも、再帰リゾルバは、チェーン回答では応答せず、従来のDNS回答にフォールバックする場合があります。
CHAIN queries can potentially send very large DNS answers. Attackers could abuse this using spoofed source IP addresses to inflict large distributed denial-of-service attacks using CHAINS as an amplification vector in their attack. While TCP is not vulnerable for this type of abuse, the UDP protocol is vulnerable to this.
CHAINクエリは、非常に大きなDNS応答を送信する可能性があります。攻撃者は、スプーフィングされたソースIPアドレスを使用してこれを悪用し、攻撃の増幅ベクトルとしてチェーンを使用して、大規模な分散型サービス拒否攻撃を行う可能性があります。 TCPはこの種の悪用に対して脆弱ではありませんが、UDPプロトコルはこれに対して脆弱です。
A recursive resolver MUST NOT return CHAIN answers to clients over UDP without source IP address verification. An example of UDP-based source IP address verification is [RFC7873]. A recursive resolver refusing a CHAIN option MUST respond with a zero-length CHAIN option to indicate support for CHAIN queries when a proper transport is used. It MUST NOT send an RCODE of REFUSED.
再帰リゾルバは、ソースIPアドレスの検証なしに、UDPを介してクライアントにチェーン応答を返してはなりません（MUST NOT）。 UDPベースのソースIPアドレス検証の例は[RFC7873]です。 CHAINオプションを拒否する再帰リゾルバは、適切なトランスポートが使用されている場合のCHAINクエリのサポートを示すために、長さ0のCHAINオプションで応答する必要があります。拒否のRCODEを送信してはなりません。
A client producing CHAIN queries reveals a little more information about its cache contents than regular DNS clients. This could be used to fingerprint a client across network reconnections. If DNS privacy is a concern, a CHAIN query client MAY try to use a DNS transport that provides privacy, such as [RFC7858] or a trusted DNS server that is contacted through a VPN connection such as IPsec.
CHAINクエリを生成するクライアントは、通常のDNSクライアントよりも、キャッシュの内容について少し多くの情報を明らかにします。これは、ネットワークの再接続全体でクライアントをフィンガープリントするために使用できます。 DNSプライバシーが懸念される場合、CHAINクエリクライアントは、[RFC7858]などのプライバシーを提供するDNSトランスポート、またはIPsecなどのVPN接続を介して接続される信頼できるDNSサーバーを使用する場合があります。
o A web browser on a client machine asks the forwarding resolver running on the local host to resolve the A record of "www.example.com." by sending a regular DNS UDP query on port 53 to 127.0.0.1.
o クライアントマシンのWebブラウザが、ローカルホストで実行されている転送リゾルバに「www.example.com」のAレコードを解決するように要求します。通常のDNS UDPクエリをポート53から127.0.0.1に送信する。
o The resolver on the client machine checks its cache and notices it already has a DNSSEC-validated entry of "com." in its cache. This includes the DNSKEY RRset with its RRSIG records. In other words, according to its cache, ".com" is DNSSEC validated as "secure" and can be used to continue a DNSSEC-validated chain.
o クライアントマシンのリゾルバはキャッシュをチェックし、DNSSEC検証済みの「com」のエントリがすでにあることに気付きます。そのキャッシュに。これには、RRSIGレコードを持つDNSKEY RRsetが含まれます。つまり、そのキャッシュによれば、「。com」は「セキュア」として検証されたDNSSECであり、DNSSEC検証済みチェーンを続行するために使用できます。
o The resolver on the client opens a TCP connection to its upstream recursive resolver on port 53. It adds the CHAIN option as follows:
o クライアントのリゾルバは、ポート53でアップストリームの再帰リゾルバへのTCP接続を開きます。次のようにCHAINオプションを追加します。
* Option-code, set to 13
* オプションコード、13に設定
* Option-length, set to 5
* オプション長、5に設定
* Closest trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
* 「com」に設定された最も近いトラストポイント。 （0x03 0x63 0x6f 0x6d 0x00）
o The upstream recursive resolver receives a DNS query over TCP with the CHAIN closest trust point set to "com.". After accepting the query, it starts constructing a DNS reply packet.
o アップストリームの再帰リゾルバーは、 "com。"に設定されたCHAINの最も近いトラストポイントを使用して、TCP経由でDNSクエリを受信します。クエリを受け入れた後、DNS応答パケットの構築を開始します。
o The upstream recursive resolver performs all the regular work to ensure it has all the answers to the query for the A record of "www.example.com.". It does so without using the CHAIN option -- unless it is also configured as a forwarding resolver. The answer to the original DNS question could be the actual A record, the DNSSEC proof of nonexistence, or an insecure NXDOMAIN response.
o 上流の再帰リゾルバは、 "www.example.com。"のAレコードに対するクエリに対するすべての回答を確実に得るために、すべての通常の作業を実行します。これは、CHAINオプションを使用せずに行われます（転送リゾルバーとしても構成されていない場合）。元のDNSの質問に対する答えは、実際のAレコード、DNSSECが存在しないことの証明、または安全でないNXDOMAIN応答である可能性があります。
o The upstream recursive resolver adds the CHAIN option to the DNS response as follows:
o アップストリームの再帰リゾルバーは、次のようにDNS応答にCHAINオプションを追加します。
* Option-code, set to 13
* オプションコード、13に設定
* Option-length, set to 5
* オプション長、5に設定
* The closest trust point is set to "com." (0x03 0x63 0x6f 0x6d 0x00)
* 最も近いトラストポイントは「com」に設定されています。 （0x03 0x63 0x6f 0x6d 0x00）
o The upstream recursive resolver constructs the DNS Authority Section and fills it (in any order) with:
o アップストリームの再帰リゾルバーはDNS権限セクションを構築し、（任意の順序で）以下を入力します。
* The DS RRset for "example.com." and its corresponding RRSIGs (made by the "com." DNSKEY(s))
* 「example.com」のDS RRset。およびそれに対応するRRSIG（「com。」DNSKEYによって作成）
* The DNSKEY RRset for "example.com." and its corresponding RRSIGs (made by the "example.com." DNSKEY(s))
* 「example.com」のDNSKEY RRset。およびそれに対応するRRSIG（「example.com。」DNSKEYによって作成）
* The authoritative NS RRset for "example.com." and its corresponding RRSIGs (from the child zone)
* 「example.com」の信頼できるNS RRset。とそれに対応するRRSIG（子ゾーンから）
If the answer does not exist, and the zone uses DNSSEC, it also adds the proof of nonexistence, such as NSEC or NSEC3 records, to the Authority Section.
回答が存在せず、ゾーンがDNSSECを使用している場合、NSECやNSEC3レコードなどの非存在の証明も機関セクションに追加されます。
o The upstream recursive resolver constructs the DNS Answer section and fills it with:
o アップストリームの再帰リゾルバーはDNS回答セクションを作成し、以下を入力します。
* The A record of "www.example.com." and its corresponding RRSIGs.
* 「www.example.com」のAレコード。および対応するRRSIG。
If the answer does not exist (NODATA or NXDOMAIN), the Answer Section remains empty. For the NXDOMAIN case, the RCODE of the DNS answer packet is set to NXDOMAIN. Otherwise, it remains as NOERROR.
回答が存在しない場合（NODATAまたはNXDOMAIN）、回答セクションは空のままです。 NXDOMAINの場合、DNS応答パケットのRCODEはNXDOMAINに設定されます。それ以外の場合は、NOERRORのままです。
o The upstream recursive resolver returns the DNS answer over the existing TCP connection. When all data is sent, it SHOULD keep the TCP connection open to allow for additional incoming DNS queries -- provided it has enough resources to do so.
o アップストリームの再帰リゾルバーは、既存のTCP接続を介してDNS応答を返します。すべてのデータが送信されると、TCP接続を開いたままにして、追加の着信DNSクエリを許可する必要があります（十分なリソースがある場合）。
o The resolver on the client receives the DNS answer. It processes the Authority and the Answer Sections and places the information in its local cache. It ensures that no data is accepted into the cache without having proper DNSSEC validation. It MAY do so by looping over the entries in the Authority and Answer Sections. When an entry is validated for its cache, it is removed from the processing list. If an entry cannot be validated, it is left in the process list. When the end of the list is reached, the list is processed again until either all entries are placed in the cache or the remaining items cannot be placed in the cache due to lack of validation. Those entries are then discarded.
o クライアントのリゾルバーはDNS応答を受け取ります。機関と回答セクションを処理し、ローカルキャッシュに情報を配置します。これにより、適切なDNSSEC検証がなければ、データがキャッシュに受け入れられなくなります。 Authority and Answer Sectionsのエントリをループすることでそうするかもしれません。エントリのキャッシュが検証されると、処理リストから削除されます。エントリを検証できない場合は、プロセスリストに残されます。リストの最後に到達すると、すべてのエントリがキャッシュに配置されるか、検証の不足により残りのアイテムをキャッシュに配置できなくなるまで、リストが再度処理されます。その後、それらのエントリは破棄されます。
o If the cache contains a valid answer to the application's query, this answer is returned to the application via a regular DNS answer packet. This packet MUST NOT contain a CHAIN option. If no valid answer can be returned, normal error processing is done. For example, an NXDOMAIN or an empty Answer Section could be returned depending on the error condition.
o キャッシュにアプリケーションのクエリに対する有効な回答が含まれている場合、この回答は通常のDNS回答パケットを介してアプリケーションに返されます。このパケットには、チェーンオプションを含めてはなりません。有効な回答が返されない場合は、通常のエラー処理が行われます。たとえば、NXDOMAINまたは空の応答セクションは、エラー条件に応じて返される可能性があります。
A recursive resolver receives a query for the A record for "example.com". It includes the CHAIN option with the following parameters:
再帰リゾルバは、 "example.com"のAレコードのクエリを受け取ります。以下のパラメーターを持つCHAINオプションが含まれています。
o Option-code, set to 13
o オプションコード、13に設定
o Option-length, set to 14
o オプション長、14に設定
o The closest trust point set to "unrelated.ca." (0x09 0x75 0x6e 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)
o 「unrelated.ca」に設定された最も近いトラストポイント。 （0x09 0x75 0x6e 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00）
As there is no chain that leads from "unrelated.ca." to "example.com.", the resolving nameserver answers with an empty CHAIN specified using:
「unrelated.ca」からつながるチェーンがないので。 「example.com。」に、解決ネームサーバーは、次を使用して指定された空のチェーンで応答します。
o Option-code, set to 13
o オプションコード、13に設定
o Option-length, set to 0x00 0x00
o オプション長、0x00 0x00に設定
o The closest trust point is omitted (zero length)
o 最も近いトラストポイントは省略されます（長さゼロ）
Note that the regular answer is still present just as it would be for a query that did not specify the CHAIN option.
CHAINオプションを指定しなかったクエリの場合と同じように、通常の回答がまだ存在することに注意してください。
A recursive resolver receives a query for the A record for "ipv6.toronto.redhat.ca". It includes the CHAIN option with the following parameters:
再帰リゾルバは、「ipv6.toronto.redhat.ca」のAレコードのクエリを受け取ります。以下のパラメーターを持つCHAINオプションが含まれています。
o Option-code, set to 13
o オプションコード、13に設定
o Option-length, set to 0x00 0x03
o オプション長、0x00 0x03に設定
o The closest trust point set to "ca."
o 「ca」に設定された最も近いトラストポイント。
Using regular UDP queries towards authoritative nameservers, it locates the NS RRset for "toronto.redhat.ca.". When querying for the A record, it receives a reply with RCODE "NoError" and an empty Answer Section. The Authority Section contains NSEC3 and RRSIG records proving there is no A RRTYPE for the QNAME "ipv6.toronto.redhat.ca".
権威のあるネームサーバーへの通常のUDPクエリを使用して、「toronto.redhat.ca。」のNS RRsetを見つけます。 Aレコードを照会すると、RCODE "NoError"と空のAnswerセクションを含む応答を受け取ります。権限セクションには、QNAME "ipv6.toronto.redhat.ca"のA RRTYPEがないことを証明するNSEC3およびRRSIGレコードが含まれています。
The recursive resolver constructs a DNS reply with the following CHAIN option parameters:
再帰リゾルバは、次のCHAINオプションパラメータを使用してDNS応答を構築します。
o Option-code, set to 13
o オプションコード、13に設定
o Option-length, set to 0x00 0x00
o オプション長、0x00 0x00に設定
o The closest trust point is omitted (zero length)
o 最も近いトラストポイントは省略されます（長さゼロ）
The RCODE is set to "NoError". The Authority Section is filled in with:
RCODEは "NoError"に設定されています。権限セクションには以下が入力されます。
o The DS RRset for "redhat.ca." plus RRSIGs
o 「redhat.ca」のDS RRset。プラスRRSIG
o The DNSKEY RRset for "redhat.ca." plus RRSIGs o The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
o「redhat.ca」のDNSKEY RRset。 plus RRSIGs o「redhat.ca」のNS RRset。プラスRRSIG（例：ns [01] .redhat.ca）
o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
o 「ns0.redhat.ca」のA RRset。および「ns1.redhat.ca」。プラスRRSIG
o The DS RRset for "toronto.redhat.ca." plus RRSIGs
o 「toronto.redhat.ca」のDS RRset。プラスRRSIG
o The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g., ns[01].toronto.redhat.ca)
o 「toronto.redhat.ca」のNS RRset。プラスRRSIG（例：ns [01] .toronto.redhat.ca）
o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
o 「toronto.redhat.ca」のDNSKEY RRset。プラスRRSIG
o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and "ns1.toronto.redhat.ca." plus RRSIGs
o 「ns0.toronto.redhat.ca」のA RRsetまたはAAAA RRset。および「ns1.toronto.redhat.ca」。プラスRRSIG
o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs do exist; does not include A)
o 「ipv6.toronto.redhat.ca」のNSECレコード。 （RRTYPEの存在を証明します。Aは含まれません）
o The NSEC record for "toronto.redhat.ca." (proves no wildcard exists)
o 「toronto.redhat.ca」のNSECレコード。 （ワイルドカードが存在しないことを証明します）
The Answer Section is empty. The RCODE is set to NOERROR.
回答セクションが空です。 RCODEはNOERRORに設定されています。
IANA has assigned option code 13 in the "DNS EDNS0 Option Codes (OPT)" registry to CHAIN.
IANAは、「DNS EDNS0オプションコード（OPT）」レジストリのオプションコード13をCHAINに割り当てました。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://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, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]アンドリュース、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<http://www.rfc-editor.org/info/rfc2308>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<http://www.rfc-editor.org/info/rfc4786> 。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// www.rfc-editor.org/info/rfc6824>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<http：// www.rfc-editor.org/info/rfc6891>。
[RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., and R. Weber, "Definition and Use of DNSSEC Negative Trust Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, <http://www.rfc-editor.org/info/rfc7646>.
[RFC7646] Ebersman、P.、Kumari、W.、Griffiths、C.、Livingood、J.、and R. Weber、 "Definition and Use of DNSSEC Negative Trust Anchors"、RFC 7646、DOI 10.17487 / RFC7646、September 2015、 <http://www.rfc-editor.org/info/rfc7646>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<http://www.rfc-editor.org/info/rfc7719 >。
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <http://www.rfc-editor.org/info/rfc7828>.
[RFC7828] Wouters、P.、Abley、J.、Dickinson、S。、およびR. Bellis、「The edns-tcp-keepalive EDNS0 Option」、RFC 7828、DOI 10.17487 / RFC7828、2016年4月、<http：// www.rfc-editor.org/info/rfc7828>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <http://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<http://www.rfc-editor.org/info/rfc7858>。
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <http://www.rfc-editor.org/info/rfc7873>.
[RFC7873] Eastlake 3rd、D。およびM. Andrews、「ドメインネームシステム（DNS）Cookie」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<http://www.rfc-editor.org/info/rfc7873 >。
Acknowledgments
謝辞
Andrew Sullivan pointed out that we do not need any new data formats to support DNS chains. Olafur Gudmundsson ensured the RRsets are returned in the proper sections. Thanks to Tim Wicinski for his thorough review.
Andrew Sullivanは、DNSチェーンをサポートするために新しいデータ形式は必要ないことを指摘しました。 Olafur Gudmundssonは、RRsetが適切なセクションで返されることを確認しました。 Tim Wicinskiの徹底的なレビューに感謝します。
Author's Address
著者のアドレス
Paul Wouters Red Hat
ポール・ウーターズレッドハット
Email: pwouters@redhat.com