Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7901 Red Hat
Category: Experimental June 2016
ISSN: 2070-1721
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扩展，可供安全感知验证解析程序使用，该解析程序配置为使用转发解析程序发送单个查询，请求完整的验证路径和常规查询答案。查询的减少可能会降低延迟，并减少一次发送多个查询的需要。此扩展强制使用源IP验证传输（如TCP或UDP）和EDNS-COOKIE，因此不能在放大攻击中滥用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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答案。当DNSSEC[RFC4033]部署在此类DNS客户端上时，验证要求客户端获取从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请求。这需要DNS客户端在状态（CPU、内存、电池）和带宽方面有更多的资源。也不能保证初始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.
本文档指定了一个EDNS0扩展，该扩展允许作为转发解析程序运行的验证解析程序打开到另一个解析程序的TCP连接，并使用一个DNS查询/应答对请求DNS链应答。这将往返次数减少到两次。如果与长寿命TCP或[RFC7828]相结合，则只有一次往返。虽然上游解析器仍然需要执行完整答案所需的所有单个查询，但它通常具有更大的缓存，并且不会经历与最后一英里延迟相比的显著减速。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
转发解析程序：本身不进行迭代解析的名称服务器；相反，它将该职责传递给另一个递归解析器，在[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工作委托给上游递归解析器。仅获取DNS应答本身不足以使用DNSSEC验证该应答。对于DNSSEC验证，DNS客户端需要一个本地运行的验证解析程序，以便它可以确认所有中间DNS应答的DNSSEC验证。如果获得一个或多个可用递归解析器的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应答所需的所有中间DNS数据。解析程序可以是应用程序的一部分，也可以是在主机上运行的递归解析程序。
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.
使用链数据应答的服务器应确保对等方的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.
空链EDNS0选项可以作为发现方法通过任何传输发送。接收此类空链选项的DNS服务器应在其答案中添加空链选项，以表明其支持该链选项。
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:
本文档使用EDNS0选项[RFC6891]在DNS消息中包含客户端IP信息。该选项的结构如下所示：
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) ~
+---------------------------------------------------------------+
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 选项代码，2个八位字节，链为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
o 最近的信任点，链的请求起点的DNS wire格式的可变长度完全限定域名（FQDN）。此项是递归服务器在DNS链中已知的“最低”项，该递归服务器寻求链答案，该链答案具有已验证的委派签名者（DS）和DNSKEY记录。这个
endpoint of the chain is obtained from the DNS Query Section itself. No DNS name compression is allowed for this value.
链的端点是从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].
转发解析器可以在任何传输上的常规查询中包括零长度链选项，以发现链的DNS服务器功能。支持并愿意接受源IP验证传输上的链查询的递归解析器通过在答案中包含零长链选项来响应接收到的零长链。如果尚未使用源IP验证的传输，则转发解析程序可切换到源IP验证的传输，并开始使用链选项发送查询，以请求递归解析程序的链响应。源IP验证传输的示例包括三向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.
链选项通常应由系统转发解析程序和同时执行DNSSEC验证的应用程序内的解析程序发送。
When CHAIN is available, the downstream recursive resolver can adjust its query strategy based on the desired queries and its cache contents.
当链可用时，下游递归解析器可以根据所需的查询及其缓存内容调整其查询策略。
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查询中请求链选项。但是，建议转发解析程序记住哪些上游递归解析程序没有随响应返回选项（和附加数据）。转发解析程序应返回到常规DNS，以便后续查询这些递归解析程序。它可能会切换到另一个支持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.
当从转发解析程序接收到包含非零链选项的查询时，支持链的上游递归解析程序可以通过确认返回链来响应。为此，它必须将链选项设置为作为链的一部分发送的最低信任点，以及相应的选项长度。它使用验证应答所需的DNS RRSET扩展DNS应答数据包中的授权部分。添加的DNS RRSET从接收到的最近信任点下方的第一个链元素开始，直到并包括表示QNAME的区域切割（权威服务器）的NS和DS RRSET。可以按匹配的层次顺序添加添加的RRSET，但DNS客户端不得依赖添加的RRSET的顺序进行验证。查询部分中问题的实际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.
没有实现或启用对链选项的支持，或者由于工作负载而不愿意为链查询执行额外工作的递归解析器，可以安全地忽略传入查询中的选项。这样的服务器在发送DNS应答时不能包含链选项，从而表明此时它不能或不愿意支持链查询。
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）的请求；FORMERR响应必须返回给发送方，如[RFC6891]所述。
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应答的方式回答查询而被拒绝，但链负载为空。用空链回复可以用于太大的链，或者用于泄露太多被认为是私有信息的链。
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.
在任何时候，确定资源不足的递归解析器都可以通过使用空链负载的常规DNS应答来拒绝链查询。
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.
全链。链响应将包含包含在链答案中的最低最近信任点。
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处理。仅当CNAME或DNAME目标的DNSSEC验证的所有支持记录也添加到授权部分时，才可将CNAME或DNAME目标放在附加部分。
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选项。
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.
包含链选项的DNS查询还必须设置“DNSSEC OK”（DO）位。如果未设置该位，或设置了“检查禁用”（CD）位，则必须忽略接收到的链选项。
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]和[RFC4035]中所述，DNS查询中包含链选项的OPT资源记录的存在或不存在不会改变这些资源记录和用于向DNS提供数据源身份验证和数据完整性的机制的使用。
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.
链响应应包括权威NS RRset及其验证所需的RRSIG记录。它不能包括来自父区域的NS RRset，因为此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.
当通过chain提供DNSSEC链时，转发解析器不再需要使用NS RRset，因为它可以通过DNSKEY和DS RRset构建验证路径，而不使用NS RRset。但是，由于网络拓扑更改，转发冲突解决程序可能会被迫从转发冲突解决程序模式切换到递归冲突解决程序模式。在递归解析器模式下，需要NS RRSET来直接查找和查询权威服务器。建议DNS转发解析程序使用此信息填充其缓存，以避免将来需要查询以获取任何丢失的NS记录。因此，链响应必须包括来自子区域的NS RRset，包括验证所需的RRSIG记录。
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 keepalive[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客户端和服务器都受到资源限制，这将限制链查询的执行范围。可以在单个客户端和服务器上维护的活动会话数的有效限制应作为配置选项或通过询问操作系统施加的进程限制来确定。
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.
如果对链查询的需求超过了可容纳的范围，DNS服务器可能会停止在连续的DNS消息中宣传链选项。例如，这允许具有其他候选服务器的客户端进行查询，以与不同的服务器建立新会话，期望这些服务器仍然允许链查询。
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.
如果链答案将与负信任锚点相交[RFC7646]，则应返回到负信任锚点上方节点的部分链。
Recursive resolvers of various types are commonly deployed using anycast [RFC4786].
各种类型的递归解析器通常使用anycast[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服务器的实现中使用选播实际上是客户端无法检测到的。除非所有选播服务器节点都能够处理链选项，否则使用UDP传输从使用选播配置的服务器进行响应时不应包括链选项。
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.
链查询可能会发送非常大的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向客户端返回链答案。基于UDP的源IP地址验证示例为[RFC7873]。拒绝链选项的递归解析器必须使用零长度链选项进行响应，以指示在使用正确传输时支持链查询。它不能发送拒绝的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.
产生链式查询的客户机比常规DNS客户机显示更多一些有关其缓存内容的信息。这可用于通过网络重新连接对客户端进行指纹识别。如果关注DNS隐私，链查询客户端可能会尝试使用提供隐私的DNS传输，如[RFC7858]或通过VPN连接（如IPsec）联系的受信任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浏览器通过在端口53至127.0.0.1上发送常规DNS UDP查询，要求在本地主机上运行的转发解析程序解析“www.example.com”的A记录。
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.”条目。这包括DNSKEY RRset及其RRSIG记录。换句话说，根据其缓存，“.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连接。它添加了“链”选项，如下所示：
* 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 上游递归解析器通过TCP接收DNS查询，链最近信任点设置为“com”。接受查询后，它开始构造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 上游递归解析器执行所有常规工作，以确保它拥有对A记录“www.example.com”的查询的所有答案。它不使用CHAIN选项，除非它也配置为转发解析器。原始DNS问题的答案可能是实际的A记录、DNSSEC不存在的证明或不安全的NXDOMAIN响应。
o The upstream recursive resolver adds the CHAIN option to the DNS response as follows:
o 上游递归解析器将链选项添加到DNS响应中，如下所示：
* 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”的记录及其相应的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或NXDOMIN），则答案部分将保持为空。对于NXDOMAIN情况，DNS应答数据包的RCODE设置为NXDOMAIN。否则，它仍然是无错误的。
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验证的情况下，不会将任何数据接受到缓存中。它可以通过在“权限”和“回答”部分的条目上循环来实现。当为缓存验证条目时，它将从处理列表中删除。如果无法验证条目，则将其保留在流程列表中。当到达列表的末尾时，将再次处理列表，直到所有条目都放置在缓存中，或者由于缺少验证而无法将其余项放置在缓存中。然后丢弃这些条目。
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记录的查询。它包括具有以下参数的“链”选项：
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记录的查询。它包括具有以下参数的“链”选项：
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”的回复和一个空的应答部分。授权部分包含NSEC3和RRSIG记录，证明QNAME“ipv6.toron.redhat.ca”没有RRTYPE。
The recursive resolver constructs a DNS reply with the following CHAIN option parameters:
递归解析器使用以下链选项参数构造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设置为“无错误”。“权限”部分填写有：
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 DNSKEY RRset为“redhat.ca.”加上RRSIG
o The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
o “redhat.ca”的NS RRset加上RRSIGs（例如，NS[01].redhat.ca）
o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
o “ns0.redhat.ca.”和“ns1.redhat.ca.”的RRA集加上RRSIG
o The DS RRset for "toronto.redhat.ca." plus RRSIGs
o “toronto.redhat.ca”的DS RRset加上RRSIGs
o The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g., ns[01].toronto.redhat.ca)
o “toronto.redhat.ca.”的NS RRset加上RRSIGs（例如，NS[01].toronto.redhat.ca）
o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
o DNSKEY RRset为“toronto.redhat.ca.”加上RRSIGs
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.”和“ns1.toronto.redhat.ca.”加上RRSIG的A RRset和/或AAAA RRset
o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs do exist; does not include A)
o NSEC“ipv6.toronto.redhat.ca.”的记录（证明RRTYPE确实存在；不包括A）
o The NSEC record for "toronto.redhat.ca." (proves no wildcard exists)
o NSEC“toronto.redhat.ca.”的记录（证明不存在通配符）
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]Andrews，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安全扩展的资源记录”，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，“任意广播服务的运营”，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 6824DOI 10.17487/RFC68242013年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/RFC68911913年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.，和R.Weber，“DNSSEC负面信任锚的定义和使用”，RFC 7646，DOI 10.17487/RFC7646，2015年9月<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/RFC77192015年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，“edns tcp keepalive EDNS0选项”，RFC 7828，DOI 10.17487/RFC78282016年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传输层安全规范（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）Cookies”，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.
安德鲁·沙利文指出，我们不需要任何新的数据格式来支持DNS链。Olafur Gudmundsson确保在适当的部分返回RRSET。感谢Tim Wicinski的全面审查。
Author's Address
作者地址
Paul Wouters Red Hat
保罗·沃特斯红帽
Email: pwouters@redhat.com
Email: pwouters@redhat.com