Internet Engineering Task Force (IETF) D. Wessels
Request for Comments: 8145 Verisign
Category: Standards Track W. Kumari
ISSN: 2070-1721 Google
P. Hoffman
ICANN
April 2017
Internet Engineering Task Force (IETF) D. Wessels
Request for Comments: 8145 Verisign
Category: Standards Track W. Kumari
ISSN: 2070-1721 Google
P. Hoffman
ICANN
April 2017
Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
DNS安全扩展（DNSSEC）中的信令信任锚知识
Abstract
摘要
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.
开发DNS安全扩展（DNSSEC）是为了通过使用数字签名为DNS数据提供源身份验证和完整性保护。这些数字签名可以通过建立信任链来验证，信任链从信任锚点开始，一直到DNS中的特定节点。本文档指定了两种不同的方法来验证解析程序，以向服务器发送信号，告知在其信任链中引用了哪些密钥。来自此类信令的数据允许区域管理员监控DNSSEC签名区域中的翻车进度。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8145.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8145.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. Design Evolution ...........................................4
2. Requirements Terminology ........................................5
3. Terminology .....................................................5
4. Using the edns-key-tag Option ...................................5
4.1. Option Format ..............................................5
4.2. Use by Queriers ............................................6
4.2.1. Stub Resolvers ......................................7
4.2.1.1. Validating Stub Resolvers ..................7
4.2.1.2. Non-validating Stub Resolvers ..............7
4.2.2. Recursive Resolvers .................................7
4.2.2.1. Validating Recursive Resolvers .............7
4.2.2.2. Non-validating Recursive Resolvers .........8
4.3. Use by Responders ..........................................8
5. Using the Key Tag Query .........................................8
5.1. Query Format ...............................................8
5.2. Use by Queriers ............................................9
5.3. Use by Responders ..........................................9
5.3.1. Interaction with Aggressive Negative Caching ........9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
8. Privacy Considerations .........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Acknowledgments ...................................................13
Authors' Addresses ................................................13
1. Introduction ....................................................3
1.1. Design Evolution ...........................................4
2. Requirements Terminology ........................................5
3. Terminology .....................................................5
4. Using the edns-key-tag Option ...................................5
4.1. Option Format ..............................................5
4.2. Use by Queriers ............................................6
4.2.1. Stub Resolvers ......................................7
4.2.1.1. Validating Stub Resolvers ..................7
4.2.1.2. Non-validating Stub Resolvers ..............7
4.2.2. Recursive Resolvers .................................7
4.2.2.1. Validating Recursive Resolvers .............7
4.2.2.2. Non-validating Recursive Resolvers .........8
4.3. Use by Responders ..........................................8
5. Using the Key Tag Query .........................................8
5.1. Query Format ...............................................8
5.2. Use by Queriers ............................................9
5.3. Use by Responders ..........................................9
5.3.1. Interaction with Aggressive Negative Caching ........9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
8. Privacy Considerations .........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Acknowledgments ...................................................13
Authors' Addresses ................................................13
The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035] were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. DNSSEC uses Key Tags to efficiently match signatures to the keys from which they are generated. The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY resource record (RR) using a formula not unlike a ones-complement checksum. RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that validates the signature.
DNS安全扩展（DNSSEC）[RFC4033][RFC4034][RFC4035]的开发目的是通过使用数字签名为DNS数据提供源身份验证和完整性保护。DNSSEC使用密钥标签有效地将签名与生成签名的密钥相匹配。密钥标记是从DNSKEY资源记录（RR）的RDATA部分计算出的16位值，使用与补码校验和相同的公式。RRSIG RRs包含一个密钥标记字段，其值等于验证签名的DNSKEY RR的密钥标记。
Likewise, Delegation Signer (DS) RRs also contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR to which it refers.
同样，委托签名者（DS）RRs还包含一个键标记字段，其值等于它所引用的DNSKEY RR的键标记。
This document specifies how validating resolvers can tell a server, in a DNS query, which DNSSEC key(s) they would use to validate the server's responses. It describes two independent methods for conveying Key Tag information between clients and servers:
本文档指定验证解析程序如何在DNS查询中告知服务器将使用哪些DNSSEC密钥验证服务器的响应。它描述了在客户端和服务器之间传输密钥标签信息的两种独立方法：
1. placing an EDNS option in the OPT RR [RFC6891] that contains the Key Tags (described in Section 4)
1. 将EDNS选项放置在包含键标记的OPT RR[RFC6891]中（如第4节所述）
2. periodically sending special "Key Tag queries" to a server authoritative for the zone (described in Section 5)
2. 定期向区域的权威服务器发送特殊的“密钥标签查询”（如第5节所述）
Each of these new signaling mechanisms is OPTIONAL to implement and use. These mechanisms serve to measure the acceptance and use of new DNSSEC trust anchors and key signing keys (KSKs). This signaling data can be used by zone administrators as a gauge to measure the successful deployment of new keys. This is of particular interest for the DNS root zone in the event of key and/or algorithm rollovers that rely on [RFC5011] to automatically update a validating DNS resolver's trust anchor.
这些新的信令机制中的每一个都是可选的，可以实现和使用。这些机制用于衡量新DNSSEC信任锚和密钥签名密钥（KSK）的接受和使用情况。区域管理员可以使用此信令数据作为衡量新密钥成功部署的标准。当密钥和/或算法翻转依赖[RFC5011]自动更新验证DNS解析程序的信任锚时，这对于DNS根区域特别重要。
This document does not introduce new processes for rolling keys or updating trust anchors. Rather, it specifies a means by which a DNS query can signal the set of keys that a client uses for DNSSEC validation.
本文档不介绍滚动密钥或更新信任锚的新过程。相反，它指定了一种方式，通过这种方式，DNS查询可以向客户端用于DNSSEC验证的密钥集发送信号。
Initially, when the work on this document started, it proposed including Key Tag values in a new EDNS(0) option code. It was modeled after [RFC6975], which provides DNSSEC algorithm signaling.
最初，当本文档的工作开始时，它建议在新的EDNS（0）选项代码中包含关键标记值。它以[RFC6975]为模型，后者提供DNSSEC算法信令。
The authors received feedback from participants in the DNSOP Working Group that it might be better to convey Key Tags in the QNAME of a separate DNS query, rather than as an EDNS(0) option. Mostly, this is because forwarding (e.g., from stub to recursive to authoritative) could be problematic. Reasons include the following:
作者收到了DNSOP工作组参与者的反馈，他们认为在单独DNS查询的QNAME中传递密钥标记可能比作为EDNS（0）选项更好。这主要是因为转发（例如，从存根到递归再到权威）可能会有问题。原因包括：
1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not be forwarded by default, as per [RFC6891].
1. EDNS（0）是一种逐跳协议。根据[RFC6891]，默认情况下不会转发未知选项代码。
2. Middleboxes might block entire queries containing unknown EDNS(0) option codes.
2. 中间盒可能会阻止包含未知EDN（0）选项代码的整个查询。
3. A recursive resolver might need to remember Key Tag values (i.e., keep state) received from its stub clients and then forward them at a later opportunity.
3. 递归解析器可能需要记住从其存根客户端接收的键标记值（即keep state），然后在以后的机会转发它们。
One advantage of the EDNS(0) option code is that it is possible to see that a stub client has a different Key Tag list than its forwarder. In the QNAME-based approach, this is not possible because queries originated by a stub and a forwarder are indistinguishable. The authors feel that this advantage is not sufficient to justify the EDNS(0) approach.
EDNS（0）选项代码的一个优点是，可以看到存根客户机与其转发器具有不同的密钥标记列表。在基于QNAME的方法中，这是不可能的，因为由存根和转发器发起的查询是不可区分的。作者认为这一优势不足以证明EDNS（0）方法的合理性。
One downside to the QNAME approach is that it uses a separate query, whereas with EDNS(0) the Key Tag values are "piggybacked" onto an existing DNSKEY query. For this reason, this document recommends only sending QNAME-based Key Tag queries for trust anchors, although EDNS-based Key Tags can be sent with any DNSKEY query.
QNAME方法的一个缺点是它使用一个单独的查询，而对于EDN（0），键标记值“背负”到现有的DNSKEY查询上。因此，本文档建议仅发送信任锚的基于QNAME的密钥标记查询，尽管基于EDNS的密钥标记可以与任何DNSKEY查询一起发送。
Another downside to the QNAME-based approach is that since the trust anchor zone might not contain labels matching the QNAME, these queries could be subject to aggressive negative caching features now in development by the Working Group. This could affect the amount of signaling sent by some clients compared to others.
基于QNAME的方法的另一个缺点是，由于信任锚区域可能不包含与QNAME匹配的标签，因此这些查询可能会受到工作组目前正在开发的激进的负面缓存特性的影响。与其他客户端相比，这可能会影响某些客户端发送的信令量。
A probably minor downside to the QNAME-based approach is that it cannot be used with extremely long query names if the addition of the prefix would cause the name to be longer than 255 octets.
基于QNAME的方法的一个可能较小的缺点是，如果添加前缀会导致名称长度超过255个八位字节，那么它不能用于非常长的查询名称。
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]中所述进行解释。
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to which the trust anchor points to be signed. (This paragraph is quoted from Section 2 of [RFC4033].)
信任锚点：DNSKEY RR的已配置DNSKEY RR或DS RR哈希。具有验证安全意识的解析器使用此公钥或哈希作为起点，以构建签名DNS响应的身份验证链。通常，验证解析程序必须通过DNS协议之外的一些安全或受信任的方式获得其信任锚的初始值。信任锚的存在还意味着解析器应该期望信任锚指向的区域被签名。（本段引用自[RFC4033]第2节。）
Key Tag: A 16-bit integer that identifies and enables efficient selection of DNSSEC public keys. A Key Tag value can be computed over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available. For most algorithms, the Key Tag is a simple 16-bit modular sum of the DNSKEY RDATA. See [RFC4034], Appendix B.
密钥标签：一个16位整数，用于识别和启用DNSSEC公钥的有效选择。可以通过DNSKEY RR的RDATA计算键标记值。当多个候选DNSKEY RR可用时，RRSIG和DS记录中的Key Tag字段可用于帮助有效选择相应的DNSKEY RR。对于大多数算法，密钥标记是DNSKEY RDATA的简单16位模和。见[RFC4034]，附录B。
The edns-key-tag option is encoded as follows:
edns密钥标签选项编码如下：
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY-TAG |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY-TAG |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
哪里：
OPTION-CODE: The EDNS0 option code assigned to edns-key-tag (14).
选项代码：分配给edns密钥标签（14）的EDNS0选项代码。
OPTION-LENGTH: The value 2 x number of key-tag values present.
OPTION-LENGTH：值2 x存在的键标记值的数量。
KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).
密钥标签：一个或多个16位密钥标签值（[RFC4034]，附录B）。
A validating resolver sets the edns-key-tag option in the OPT RR when sending a DNSKEY query. The validating resolver SHOULD also set the DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response.
验证解析器在发送DNSKEY查询时在OPT RR中设置edns密钥标记选项。验证解析器还应设置DNSSEC OK位（也称为DO位）[RFC4035]以指示其希望在响应中接收DNSSEC RRs。
A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY queries.
DNS客户端不得包含用于非DNSKEY查询的edns密钥标记选项。
The KEY-TAG value(s) included in the edns-key-tag option represents the Key Tag of the trust anchor or DNSKEY RR that will be used to validate the expected response. When the client sends a DNSKEY query, the edns-key-tag option represents the Key Tag(s) of the KSK(s) of the zone for which the server is authoritative. A validating resolver learns the Key Tag(s) of the KSK(s) from the zone's DS record(s) (found in the parent) or from a trust anchor.
edns密钥标记选项中包含的密钥标记值表示将用于验证预期响应的信任锚点或DNSKEY RR的密钥标记。当客户端发送DNSKEY查询时，edns key tag选项表示服务器授权的区域的KSK的key tag。验证冲突解决程序从区域的DS记录（在父级中找到）或信任锚中学习KSK的密钥标记。
A DNS client SHOULD include the edns-key-tag option when issuing a DNSKEY query for a zone corresponding to a trust anchor.
DNS客户端在对信任锚对应的区域发出DNSKEY查询时，应包括edns密钥标记选项。
A DNS client MAY include the edns-key-tag option when issuing a DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via DS records). Since some DNSSEC validators implement bottom-up validation, a non-trust anchor Key Tags zone might not be known at the time of the query. Such a validator can include the edns-key-tag option based on previously cached data.
DNS客户端在针对非信任锚定区域（即，通过DS记录学习的密钥标签）发出DNSKEY查询时可包括edns密钥标签选项。由于某些DNSSEC验证器实现自底向上的验证，因此在查询时可能不知道非信任锚点密钥标记区域。这样的验证器可以包括基于先前缓存的数据的edns密钥标记选项。
A DNS client MUST NOT include Key Tag(s) for keys that are not learned via either a trust anchor or DS records.
DNS客户端不得包含未通过信任锚或DS记录学习的密钥的密钥标签。
Since the edns-key-tag option is only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values.
由于edns密钥标记选项仅在查询中设置，因此如果客户端在响应中看到这些选项，则无需采取任何操作，客户端必须忽略选项值。
Typically, stub resolvers rely on an upstream recursive resolver (or cache) to provide a response. Optimal setting of the edns-key-tag option depends on whether the stub resolver elects to perform its own validation.
通常，存根解析器依赖于上游递归解析器（或缓存）来提供响应。edns密钥标记选项的最佳设置取决于存根解析器是否选择执行自己的验证。
A validating stub resolver sets the DNSSEC OK bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG RRs) in the response. Such validating resolvers SHOULD include the edns-key-tag option in the OPT RR when sending a DNSKEY query.
验证存根解析器设置DNSSEC OK位[RFC4035]以指示其希望在响应中接收额外的DNSSEC RRs（即RRSIG RRs）。发送DNSKEY查询时，此类验证解析器应在OPT RR中包含edns密钥标记选项。
The edns-key-tag option MUST NOT be included by non-validating stub resolvers.
非验证存根解析器不得包含edns密钥标记选项。
A validating recursive resolver is, by definition, configured with at least one trust anchor. Thus, a recursive resolver SHOULD include the edns-key-tag option in its DNSKEY queries as described above.
根据定义，验证递归解析器至少配置了一个信任锚。因此，如上所述，递归解析器应在其DNSKEY查询中包含edns密钥标记选项。
In addition, the clients of a validating recursive resolver might be configured to do their own validation, with their own trust anchor(s). When a validating recursive resolver receives a query that includes the edns-key-tag option with a Key Tag list that differs from its own, it SHOULD forward both the client's Key Tag list and its own list. When doing so, the recursive resolver SHOULD transmit the two Key Tag lists using separate instances of the edns-key-tag option code in the OPT RR. For example, if the recursive resolver's Key Tag list is (19036, 12345) and the stub/client's list is (19036, 34567), the recursive resolver would include the edns-key-tag option twice: once with values (19036, 12345) and once with values (19036, 34567).
此外，验证递归解析器的客户端可以配置为使用自己的信任锚进行自己的验证。当验证递归解析器接收到包含edns密钥标记选项的查询时，该查询的密钥标记列表与其自身的密钥标记列表不同，它应转发客户端的密钥标记列表及其自身的列表。执行此操作时，递归解析器应使用OPT RR中edns密钥标记选项代码的单独实例传输两个密钥标记列表。例如，如果递归解析器的密钥标记列表为（1903612345），而存根/客户端列表为（1903634567），则递归解析器将包含edns密钥标记选项两次：一次包含值（1903612345），一次包含值（1903634567）。
A validating recursive resolver MAY combine stub/client Key Tag values from multiple incoming queries into a single outgoing query. It is RECOMMENDED that implementations place reasonable limits on the number of Key Tags to include in the outgoing edns-key-tag option.
验证递归解析器可以将来自多个传入查询的存根/客户端密钥标记值组合到单个传出查询中。建议实施对要包含在传出edns密钥标签选项中的密钥标签数量进行合理限制。
If the client included the DNSSEC OK and Checking Disabled (CD) bits but did not include the edns-key-tag option in the query, the validating recursive resolver MAY include the option with its own Key Tag values in full.
如果客户端包含DNSSEC OK和Checking Disabled（CD）位，但在查询中未包含edns key tag选项，则验证递归解析器可能会包含该选项及其自身的完整key tag值。
Validating recursive resolvers MUST NOT set the edns-key-tag option in the final response to the stub client.
验证递归解析器不得在对存根客户端的最终响应中设置edns密钥标记选项。
Recursive resolvers that do not validate responses SHOULD copy the edns-key-tag option seen in received queries, as they represent the wishes of the validating downstream resolver that issued the original query.
不验证响应的递归解析器应复制接收到的查询中的edns密钥标记选项，因为它们代表发出原始查询的验证下游解析器的意愿。
An authoritative name server receiving queries with the edns-key-tag option MAY log or otherwise collect the Key Tag values to provide information to the zone operator.
使用edns密钥标记选项接收查询的权威名称服务器可以记录或以其他方式收集密钥标记值，以向区域操作员提供信息。
A responder MUST NOT include the edns-key-tag option in any DNS response.
响应程序不得在任何DNS响应中包含edns密钥标记选项。
A Key Tag query consists of a standard DNS query of type NULL and of class IN [RFC1035].
密钥标记查询由[RFC1035]中类型为NULL和类的标准DNS查询组成。
The first component of the query name is the string "_ta-" followed by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag values. The zone name corresponding to the trust anchor is appended to this first component.
查询名称的第一个组成部分是字符串“_ta-”，后面是一个排序的、以连字符分隔的十六进制编码键标记值列表。与信任锚点对应的区域名称将附加到此第一个组件。
For example, a validating DNS resolver that has a single root zone trust anchor with Key Tag 17476 (decimal) would originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
例如，具有单个根区域信任锚点且密钥标记为17476（十进制）的验证DNS解析程序将发起形式为QTYPE=NULL、QCLASS=IN、QNAME=_ta-4444的查询。
Hexadecimal values MUST be zero-padded to four hexadecimal digits. For example, if the Key Tag is 999 (decimal), it is represented in hexadecimal as 03e7.
十六进制值必须由零填充到四个十六进制数字。例如，如果键标记为999（十进制），则它以十六进制表示为03e7。
When representing multiple Key Tag values, they MUST be sorted in order from smallest to largest. For example, a validating DNS resolver that has three trust anchors for the example.com zone with Key Tags 1589, 43547, 31406 (decimal) would originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.
当表示多个键标记值时，它们必须按从最小到最大的顺序排序。例如，对于example.com区域，一个验证DNS解析程序有三个信任锚，其密钥标记为1589、43547、31406（十进制），它将发起一个形式为QTYPE=NULL、QCLASS=IN、QNAME=_ta-0635-7aae-aa1b.example.com的查询。
A validating DNS resolver (stub or recursive) SHOULD originate a Key Tag query whenever it also originates a DNSKEY query for a trust anchor zone. In other words, the need to issue a DNSKEY query is also the trigger to issue a Key Tag query.
验证DNS解析程序（存根或递归）在为信任锚区域发起DNSKEY查询时，应发起密钥标记查询。换句话说，发出DNSKEY查询的需要也是发出键标记查询的触发器。
The value(s) included in the Key Tag query represents the Key Tag(s) of the trust anchor that will be used to validate the expected DNSKEY response.
密钥标记查询中包含的值表示将用于验证预期DNSKEY响应的信任锚点的密钥标记。
A validating DNS resolver SHOULD NOT originate Key Tag queries when also originating DNSKEY queries for non-trust anchor zones.
验证DNS解析器在为非信任锚定区域发起DNSKEY查询时，不应发起密钥标记查询。
A non-validating DNS resolver MUST NOT originate Key Tag queries.
非验证DNS解析程序不得发起密钥标记查询。
DNS resolvers with caches SHOULD cache and reuse the response to a Key Tag query just as it would any other response.
具有缓存的DNS解析程序应该缓存和重用对密钥标记查询的响应，就像缓存和重用任何其他响应一样。
An authoritative name server receiving Key Tag queries MAY log or otherwise collect the Key Tag values to provide information to the zone operator.
接收密钥标记查询的权威名称服务器可以记录或以其他方式收集密钥标记值，以向区域操作员提供信息。
An authoritative name server MUST generate an appropriate response to the Key Tag query. A server does not need to have built-in logic that determines the response to Key Tag queries: the response code is determined by whether the data is in the zone file or covered by wildcards. The zone operator might want to add specific Key Tag records to its zone, perhaps with specific TTLs, to affect the frequency of Key Tag queries from clients.
权威名称服务器必须生成对密钥标记查询的适当响应。服务器不需要具有确定对密钥标记查询的响应的内置逻辑：响应代码由数据是在区域文件中还是由通配符覆盖而确定。区域操作员可能希望将特定的密钥标记记录添加到其区域，可能使用特定的TTL，以影响来自客户端的密钥标记查询的频率。
Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also affect the quality of Key Tag signaling. When the response code for a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive negative caching will send fewer Key Tag queries than resolvers that do not implement it.
攻击性NSEC/NSEC3负缓存[NSEC-NSEC3-USERING]也可能会影响密钥标记信令的质量。当密钥标记查询的响应代码为NXDOMAIN时，实现主动负缓存的DNS解析程序发送的密钥标记查询将少于未实现它的解析程序。
For this reason, zone operators might choose to create records corresponding to expected Key Tag queries. During a rollover from Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the following records:
因此，区域操作员可能会选择创建与预期的键标记查询相对应的记录。在从钥匙标签1111（十六进制）到钥匙标签2222（十六进制）的翻转过程中，区域可能包括以下记录：
_ta-1111 IN NULL \# 0 _ta-2222 IN NULL \# 0 _ta-1111-2222 IN NULL \# 0
_ta-1111在空\#0中ta-2222在空\#0中ta-1111-2222在空\#0中
Recall that when multiple Key Tags are present, the originating client MUST sort them from smallest to largest in the query name.
回想一下，当存在多个键标记时，原始客户端必须在查询名称中将它们从最小到最大排序。
IANA has assigned an EDNS0 option code for the edns-key-tag option in the "DNS EDNS0 Option Codes (OPT)" registry as follows:
IANA已为“DNS EDNS0选项代码（OPT）”注册表中的edns密钥标记选项分配了EDNS0选项代码，如下所示：
+-------+--------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------+----------+-----------+
| 14 | edns-key-tag | Optional | RFC 8145 |
+-------+--------------+----------+-----------+
+-------+--------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------+----------+-----------+
| 14 | edns-key-tag | Optional | RFC 8145 |
+-------+--------------+----------+-----------+
This document specifies two ways for a client to signal its trust anchor knowledge to a cache or server. The goal of these optional mechanisms is to signal new trust anchor uptake in clients to allow zone administrators to know when it is possible to complete a key rollover in a DNSSEC-signed zone.
本文档指定了客户端向缓存或服务器发送其信任锚知识的两种方式。这些可选机制的目标是向客户端发送新的信任锚点接收信号，以允许区域管理员知道何时可以在DNSSEC签名的区域中完成密钥翻转。
There is a possibility that an eavesdropper or server could infer the validator in use by a client by the Key Tag list seen. This may allow an attacker to find validators using old, possibly broken, keys. It could also be used to identify the validator or to narrow down the possible validator implementations in use by a client; the validator used by the client could have a known vulnerability that could be exploited by the attacker.
窃听者或服务器可能通过看到的密钥标记列表推断出客户端正在使用的验证器。这可能允许攻击者使用旧的、可能已损坏的密钥查找验证程序。它还可以用来识别验证器，或者缩小客户机使用的验证器实现的范围；客户端使用的验证程序可能存在已知漏洞，攻击者可能会利用该漏洞进行攻击。
Consumers of data collected from the mechanisms described in this document are advised that provided Key Tag values might be "made up" by some DNS clients with malicious, or at least mischievous, intentions. For example, an attacker with sufficient resources might try to generate large numbers of queries including only old Key Tag values, with the intention of delaying the completion of a key rollover.
建议从本文档中描述的机制收集的数据的使用者，所提供的密钥标记值可能是由一些具有恶意或至少恶意意图的DNS客户端“编造”的。例如，拥有足够资源的攻击者可能试图生成大量查询，其中仅包含旧的密钥标记值，目的是延迟密钥翻转的完成。
DNSSEC does not require keys in a zone to have unique Key Tags. During a rollover, there is a small possibility that an old key and a new key will have identical Key Tag values. Zone operators relying on the edns-key-tag mechanism SHOULD take care to ensure that new keys have unique Key Tag values.
DNSSEC不要求区域中的密钥具有唯一的密钥标记。在翻滚过程中，旧密钥和新密钥具有相同密钥标记值的可能性很小。依赖edns密钥标记机制的区域操作员应注意确保新密钥具有唯一的密钥标记值。
This proposal provides additional, optional "signaling" to DNS queries in the form of Key Tag values. While Key Tag values themselves are not considered private information, it may be possible for an eavesdropper to use Key Tag values as a fingerprinting technique to identify particular validating DNS clients. This may be especially true if the validator is configured with trust anchors for zones in addition to the root zone.
该方案以密钥标记值的形式向DNS查询提供附加的可选“信令”。虽然密钥标签值本身不被视为私有信息，但窃听者可能使用密钥标签值作为指纹技术来识别特定的验证DNS客户端。如果验证器除了根区域之外还为区域配置了信任锚，那么这可能尤其正确。
A validating resolver need not transmit the Key Tags in every applicable query. Due to privacy concerns, such a resolver MAY choose to transmit the Key Tags for a subset of queries (e.g., every 25th time) or by random chance with a certain probability (e.g., 5%).
验证解析器不需要在每个适用的查询中传输密钥标记。出于隐私考虑，这样的解析器可以选择传输查询子集的密钥标签（例如，每25次），或者以一定的概率（例如，5%）随机发送。
Implementations of this specification MAY be administratively configured to only transmit the Key Tags for certain zones. For example, the software's configuration file may specify a list of zones for which the use of the mechanisms described here is allowed or denied. Since the primary motivation for this specification is to provide operational measurement data for root zone key rollovers, it is RECOMMENDED that implementations at least include the edns-key-tag option for root zone DNSKEY queries.
本规范的实现可被管理地配置为仅传输特定区域的密钥标签。例如，软件的配置文件可以指定允许或拒绝使用此处描述的机制的区域列表。由于本规范的主要目的是为根区域密钥翻转提供操作测量数据，因此建议实施至少包括根区域DNSKEY查询的edns密钥标记选项。
[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>.
[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>.
[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>.
[NSEC-NSEC3-Usage] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of DNSSEC-validated Cache", Work in Progress, draft-ietf-dnsop-nsec-aggressiveuse-09, March 2017.
[NSEC-NSEC3-Usage]藤原，K.，加藤，A.，和W.库马里，“DNSSEC验证缓存的积极使用”，正在进行的工作，草稿-ietf-dnsop-NSEC-AggressiveEUSE-092017年3月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<http://www.rfc-editor.org/info/rfc5011>.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, <http://www.rfc-editor.org/info/rfc6975>.
[RFC6975]Crocker，S.和S.Rose，“DNS安全扩展（DNSSEC）中的信号加密算法理解”，RFC 6975，DOI 10.17487/RFC6975，2013年7月<http://www.rfc-editor.org/info/rfc6975>.
Acknowledgments
致谢
This document was inspired by and borrows heavily from [RFC6975] by Scott Rose and Steve Crocker. The authors would like to thank Mark Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim Wicinski, Suzanne Woolf, and other members of the DNSOP Working Group for their input.
本文件受斯科特·罗斯（Scott Rose）和史蒂夫·克罗克（Steve Crocker）的[RFC6975]启发，并大量借鉴了他们的经验。作者要感谢Mark Andrews、Casey Deccio、Burt Kalisky、Bob Harold、Edward Lewis、Tim Wicinski、Suzanne Woolf和DNSOP工作组其他成员的投入。
Authors' Addresses
作者地址
Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 United States of America
杜安·韦塞尔Verisign 12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
Phone: +1 703 948-3200
Email: dwessels@verisign.com
URI: http://verisigninc.com
Phone: +1 703 948-3200
Email: dwessels@verisign.com
URI: http://verisigninc.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari谷歌1600圆形剧场公园道山景，加利福尼亚州94043美利坚合众国
Email: warren@kumari.net
Email: warren@kumari.net
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org