Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 8509 J. Damas
Category: Standards Track APNIC
ISSN: 2070-1721 W. Kumari
Google
December 2018
Internet Engineering Task Force (IETF) G. Huston
Request for Comments: 8509 J. Damas
Category: Standards Track APNIC
ISSN: 2070-1721 W. Kumari
Google
December 2018
A Root Key Trust Anchor Sentinel for DNSSEC
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 a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.
开发DNS安全扩展（DNSSEC）是为了通过使用数字签名为DNS数据提供源身份验证和完整性保护。这些数字签名可以通过建立信任链来验证，信任链从信任锚点开始，一直到DNS中的特定节点。本文档指定了一种机制，允许最终用户和第三方确定处理该用户DNS查询的解析程序根密钥的受信任密钥状态。请注意，此方法仅适用于确定哪些密钥位于根密钥的信任存储中。
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 https://www.rfc-editor.org/info/rfc8509.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8509.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 4
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Special Processing . . . . . . . . . . . . . . . . . . . 6
3. Sentinel Tests for a Single DNS Resolver . . . . . . . . . . 7
3.1. Forwarders . . . . . . . . . . . . . . . . . . . . . . . 9
4. Sentinel Tests for Multiple Resolvers . . . . . . . . . . . . 10
4.1. Test Scenario and Objective . . . . . . . . . . . . . . . 11
4.2. Test Assumptions . . . . . . . . . . . . . . . . . . . . 11
4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Protocol Walk-Through Example . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 4
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Special Processing . . . . . . . . . . . . . . . . . . . 6
3. Sentinel Tests for a Single DNS Resolver . . . . . . . . . . 7
3.1. Forwarders . . . . . . . . . . . . . . . . . . . . . . . 9
4. Sentinel Tests for Multiple Resolvers . . . . . . . . . . . . 10
4.1. Test Scenario and Objective . . . . . . . . . . . . . . . 11
4.2. Test Assumptions . . . . . . . . . . . . . . . . . . . . 11
4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Protocol Walk-Through Example . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034], and [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 of a DNSKEY Resource Record (RR) as described in Appendix B of [RFC4034]. RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that was used to generate the corresponding signature.
DNS安全扩展（DNSSEC）[RFC4033]、[RFC4034]和[RFC4035]的开发目的是通过使用数字签名为DNS数据提供源身份验证和完整性保护。DNSSEC使用密钥标签有效地将签名与生成签名的密钥相匹配。密钥标签是根据DNSKEY资源记录（RR）的RDATA计算的16位值，如[RFC4034]附录B所述。RRSIG RRs包含一个密钥标记字段，其值等于用于生成相应签名的DNSKEY RR的密钥标记。
This document specifies how security-aware DNS resolvers that perform validation of their responses can respond to certain queries in a manner that allows an agent performing the queries to deduce whether a particular key for the root has been loaded into that resolver's trusted-key store. This document also describes a procedure where a collection of resolvers can be tested to determine whether at least one of these resolvers has loaded a given key into its trusted-key store. These tests can be used to determine whether a certain root zone Key Signing Key (KSK) is ready to be used as a trusted key, within the context of a planned root zone KSK roll.
本文档指定了执行响应验证的安全意识DNS解析程序如何以允许执行查询的代理推断根的特定密钥是否已加载到该解析程序的受信任密钥存储中的方式响应某些查询。本文档还描述了一个过程，在此过程中，可以测试一组冲突解决程序，以确定这些冲突解决程序中是否至少有一个已将给定密钥加载到其受信任密钥存储中。这些测试可用于确定在计划的根区域密钥签名密钥（KSK）滚动的上下文中，某个根区域密钥签名密钥（KSK）是否已准备好用作受信任密钥。
There are two primary use cases for this mechanism:
此机制有两个主要用例：
o Users may wish to ascertain whether their DNS resolution environment's resolver is ready for an upcoming root KSK rollover.
o 用户可能希望确定其DNS解析环境的解析器是否已准备好进行即将到来的根KSK滚动。
o Researchers want to perform Internet-wide studies about the proportion of users who will be negatively impacted by an upcoming root KSK rollover.
o 研究人员希望在互联网范围内对即将到来的根KSK滚动对用户造成负面影响的比例进行研究。
The mechanism described in this document satisfies the requirements of both these use cases. This mechanism is OPTIONAL to implement and use. If implemented, this mechanism SHOULD be enabled by default to facilitate Internet-wide measurement. Configuration options MAY be provided to disable the mechanism for reasons of local policy.
本文档中描述的机制满足这两个用例的要求。此机制是可选的，可以实现和使用。如果实施，默认情况下应启用此机制，以便于在Internet范围内进行测量。由于本地策略的原因，可以提供配置选项来禁用该机制。
The KSK sentinel tests described in this document use a test comprising a set of DNS queries to domain names that have special values for the leftmost label. The test relies on recursive resolvers supporting a mechanism that recognizes this special name pattern in queries; under certain defined circumstances, it will return a DNS SERVFAIL response code (RCODE 2), mimicking the response code that is returned by security-aware resolvers when DNSSEC validation fails.
本文档中描述的KSK sentinel测试使用一个测试，该测试包括一组对域名的DNS查询，这些域名的最左侧标签具有特殊值。该测试依赖于递归解析器，该解析器支持在查询中识别这种特殊名称模式的机制；在某些已定义的情况下，它将返回DNS SERVFAIL响应代码（RCODE 2），模拟DNSSEC验证失败时安全感知解析程序返回的响应代码。
If a browser or operating system is configured with multiple resolvers, and those resolvers have different properties (for example, one performs DNSSEC validation and one does not), the sentinel test described in this document can still be used. The sentinel test makes a number of assumptions about DNS resolution behavior that may not necessarily hold in all environments; if these assumptions do not hold, then this test may produce indeterminate or inconsistent results. This might occur, for example, if the stub resolver is required to query the next recursive resolver in the locally configured set upon receipt of a SERVFAIL response code. In some cases where these assumptions do not hold, repeating the same test query set may generate different results.
如果浏览器或操作系统配置了多个解析器，并且这些解析器具有不同的属性（例如，一个执行DNSSEC验证，另一个不执行），则仍可使用本文档中描述的sentinel测试。sentinel测试对DNS解析行为做出了许多假设，但这些假设未必适用于所有环境；如果这些假设不成立，则该测试可能产生不确定或不一致的结果。例如，如果在接收到SERVFAIL响应代码时要求存根解析器查询本地配置集中的下一个递归解析器，则可能会发生这种情况。在这些假设不成立的某些情况下，重复相同的测试查询集可能会生成不同的结果。
Note that the measurements facilitated by the mechanism described in this document are different from those of [RFC8145]. RFC 8145 relies on resolvers reporting towards the root servers a list of locally cached trust anchors for the root zone. Those reports can be used to infer how many resolvers may be impacted by a KSK roll but not what the user impact of the KSK roll will be.
请注意，本文件中描述的机制促进的测量与[RFC8145]中的测量不同。RFC 8145依赖解析程序向根服务器报告根区域的本地缓存信任锚点列表。这些报告可用于推断有多少解析器可能受到KSK滚动的影响，而不是KSK滚动的用户影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document contains a number of terms related to the DNS. The current definitions of these terms can be found in [RFC7719].
本文档包含许多与DNS相关的术语。这些术语的当前定义见[RFC7719]。
DNSSEC-validating resolvers that implement this mechanism MUST perform validation of responses in accordance with the DNSSEC response validation specification [RFC4035].
实现此机制的DNSSEC验证解析器必须根据DNSSEC响应验证规范[RFC4035]执行响应验证。
This sentinel mechanism makes use of two special labels:
此sentinel机制使用两个特殊标签：
o root-key-sentinel-is-ta-<key-tag>
o 根密钥哨兵是ta-<key tag>
o root-key-sentinel-not-ta-<key-tag>
o 根密钥哨兵不是ta-<key tag>
These labels trigger special processing in the validating DNS resolver when responses from authoritative servers are received. Labels containing "root-key-sentinel-is-ta-<key-tag>" are used to answer the question, "Is this the Key Tag of a key that the validating DNS resolver is currently trusting as a trust anchor?"
当接收到来自权威服务器的响应时，这些标签触发验证DNS解析程序中的特殊处理。包含“root key sentinel is ta-<key tag>”的标签用于回答以下问题：“这是验证DNS解析程序当前信任为信任锚的密钥的密钥标签吗？”
Labels containing "root-key-sentinel-not-ta-<key-tag>" are used to answer the question, "Is this the Key Tag of a key that the validating DNS resolver is *not* currently trusting as a trust anchor?"
包含“root key sentinel not ta-<key tag>”的标签用于回答以下问题：“这是验证DNS解析程序*当前不*信任的密钥的密钥标记吗？”
The special labels defined here were chosen after extensive IETF evaluation of alternative patterns and approaches in light of the desired behavior (Sections 2.1 and 2.2) within the resolver and the applied testing methodology (Section 4.3). As one example, underscore-prefixed names were rejected because some browsers and operating systems would not fetch them because they are domain names but not valid hostnames (see [RFC7719] for these definitions). Consideration was given to local collisions and the reservation of leftmost labels of a domain name, as well as the impact upon zone operators who might desire to use a similarly constructed hostname for a purpose other than those documented here. Therefore, it is important to note that the reservation of the labels in this manner is definitely not considered "best practice".
此处定义的特殊标签是在根据解析器内的预期行为（第2.1节和第2.2节）和应用测试方法（第4.3节）对替代模式和方法进行广泛IETF评估后选择的。例如，下划线前缀名称被拒绝，因为某些浏览器和操作系统无法获取它们，因为它们是域名，但不是有效的主机名（有关这些定义，请参阅[RFC7719]）。考虑了本地冲突和保留域名最左边的标签，以及对可能希望将类似构造的主机名用于本文所述目的以外的目的的区域操作员的影响。因此，必须指出，以这种方式保留标签绝对不被视为“最佳做法”。
All of the following conditions must be met to trigger special processing inside resolver code:
必须满足以下所有条件才能触发解析器代码内部的特殊处理：
o The DNS response is DNSSEC validated.
o DNS响应已通过DNSSEC验证。
o The result of validation is "Secure".
o 验证的结果是“安全的”。
o The Extension Mechanisms for DNS (EDNS(0)) Checking Disabled (CD) bit in the query is not set.
o 未设置查询中DNS（EDNS（0））检查禁用（CD）位的扩展机制。
o The QTYPE is either A or AAAA (Query Type value 1 or 28).
o QTYPE为A或AAAA（查询类型值1或28）。
o The OPCODE is QUERY.
o 操作码是查询。
o The leftmost label of the original QNAME (the name sent in the Question Section in the original query) is either "root-key-sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>".
o 原始QNAME（原始查询中问题部分发送的名称）的最左侧标签是“根密钥sentinel是ta-<key tag>”或“根密钥sentinel不是ta-<key tag>”。
If any one of the preconditions is not met, the resolver MUST NOT alter the DNS response based on the mechanism in this document.
如果不满足任何一个前提条件，解析程序不得基于本文档中的机制更改DNS响应。
Note that the <key-tag> is specified in the DNS label as an unsigned decimal integer (as described in [RFC4034], Section 5.3) but is zero-padded to five digits (for example, a Key Tag value of 42 would be represented in the label as 00042). The precise specification of the special labels above should be followed exactly. For example, a label that does not include a Key Tag zero-padded to five digits does
请注意，<key tag>在DNS标签中被指定为无符号十进制整数（如[RFC4034]第5.3节所述），但被零填充为五位数字（例如，key tag值42将在标签中表示为00042）。应严格遵守上述特殊标签的精确规格。例如，不包含填充为五位数字的键标记零的标签
not match this specification and should not be processed as if it did -- in other words, such queries should be handled as any other label and not according to Section 2.2.
与本规范不匹配，并且不应像它那样进行处理——换句话说，此类查询应作为任何其他标签处理，而不是根据第2.2节进行处理。
Responses that fulfill all of the preconditions in Section 2.1 require special processing, depending on the leftmost label in the QNAME.
满足第2.1节中所有先决条件的响应需要特殊处理，具体取决于QNAME中最左边的标签。
First, the resolver determines if the numerical value of <key-tag> is equal to any of the Key Tag values of an active root zone KSK that is currently trusted by the local resolver and stored in its store of trusted keys. An active root zone KSK is one that could currently be used for validation (that is, a key that is not in either the AddPend or Revoked state, as described in [RFC5011]).
首先，冲突解决程序确定<key tag>的数值是否等于当前受本地冲突解决程序信任并存储在其受信任密钥存储中的活动根区域KSK的任何密钥标签值。活动根区域KSK是当前可用于验证的密钥（即，未处于AddPend或Reversed状态的密钥，如[RFC5011]中所述）。
Second, the resolver alters the response being sent to the original query based on both the leftmost label and the presence of a key with given Key Tag in the trust-anchor store. Two labels and two possible states of the corresponding key generate four possible combinations, summarized in the table:
其次，解析器根据最左边的标签和信任锚点存储中存在的具有给定密钥标记的密钥来更改发送到原始查询的响应。对应键的两个标签和两种可能状态生成四种可能的组合，总结在表中：
Label | Key is trusted | Key is not trusted
------------------------------------------------------------------
is-ta | return original answer | return SERVFAIL
not-ta | return SERVFAIL | return original answer
Label | Key is trusted | Key is not trusted
------------------------------------------------------------------
is-ta | return original answer | return SERVFAIL
not-ta | return SERVFAIL | return original answer
The instruction "return SERVFAIL" means that the resolver MUST set RCODE=SERVFAIL (value 2) and the Answer Section of the DNS response MUST be empty, ignoring all other documents that specify the content of the Answer Section.
指令“return SERVFAIL”表示解析程序必须设置RCODE=SERVFAIL（值2），DNS响应的应答部分必须为空，忽略指定应答部分内容的所有其他文档。
The instruction "return original answer" means that the resolver MUST process the query without any further special processing, that is, exactly as if the mechanism described in this document was not implemented or was disabled. The answer for the A or AAAA query is sent on to the client.
指令“返回原始答案”意味着解析程序必须在不进行任何进一步特殊处理的情况下处理查询，也就是说，与未实现或禁用本文档中描述的机制完全相同。A或AAAA查询的答案将发送到客户端。
This section describes the use of the sentinel detection mechanism against a single DNS recursive resolver in order to determine whether this resolver is using a particular trust anchor to validate DNSSEC-signed responses.
本节介绍对单个DNS递归解析程序使用sentinel检测机制，以确定此解析程序是否使用特定的信任锚来验证DNSSEC签名的响应。
Note that the test in this section applies to a single DNS resolver. The test described in Section 4 applies instead to a collection of DNS resolvers, as might be found in the DNS configuration of an end-user environment.
请注意，本节中的测试适用于单个DNS解析器。第4节中描述的测试适用于DNS解析程序的集合，这可能在最终用户环境的DNS配置中找到。
The critical aspect of the DNS names used in this mechanism is that they contain the specified label for either the positive or negative test as the leftmost label in the query name.
此机制中使用的DNS名称的关键方面是，它们包含正测试或负测试的指定标签，作为查询名称中最左侧的标签。
The sentinel detection procedure can test a DNS resolver using three queries:
sentinel检测过程可以使用三个查询测试DNS解析器：
o A query name containing the leftmost label "root-key-sentinel-is-ta-<key-tag>". This corresponds to a validly signed name in the parent zone, so that responses associated with this query name can be authenticated by a DNSSEC-validating resolver. Any validly signed DNS zone can be used as the parent zone for this test.
o 包含最左侧标签“根键sentinel is ta-<key tag>”的查询名称。这对应于父区域中的有效签名名称，因此与此查询名称关联的响应可以由DNSSEC验证解析程序进行身份验证。任何有效签名的DNS区域都可以用作此测试的父区域。
o A query name containing the leftmost label "root-key-sentinel-not-ta-<key-tag>". This also corresponds to a validly signed name. Any validly signed DNS zone can be used as the parent zone for this test.
o 一个查询名称，包含最左边的标签“根键sentinel not ta-<key tag>”。这也对应于有效签名的名称。任何有效签名的DNS区域都可以用作此测试的父区域。
o A query name that is signed with a DNSSEC signature that cannot be validated (described as a "bogus" RRset in Section 5 of [RFC4033] when, for example, an RRset is associated with a zone that is not signed with a valid RRSIG record).
o 使用无法验证的DNSSEC签名签名的查询名称（例如，当RRset与未使用有效RRSIG记录签名的区域关联时，在[RFC4033]第5节中称为“伪”RRset）。
The responses received from queries to resolve each of these query names can be evaluated to infer a trust key state of the DNS resolver.
从解析每个查询名称的查询接收到的响应可以进行评估，以推断DNS解析程序的信任密钥状态。
An essential assumption here is that this technique relies on security-aware (DNSSEC-validating) resolvers responding with a SERVFAIL response code to queries where DNSSEC checking is requested and the response cannot be validated. Note that other issues can also cause a resolver to return SERVFAIL responses, and so the sentinel processing may sometimes result in incorrect or indeterminate conclusions.
这里的一个基本假设是，该技术依赖于安全感知（DNSSEC验证）解析器，该解析器使用SERVFAIL响应代码响应请求DNSSEC检查但无法验证响应的查询。请注意，其他问题也可能导致解析程序返回SERVFAIL响应，因此sentinel处理有时可能会导致错误或不确定的结论。
To describe this process of classification, DNS resolvers are classified by five distinct behavior types using the labels: "Vnew", "Vold", "Vind", "nonV", and "other". These labels correspond to resolver-system behavior types as follows:
为了描述这个分类过程，DNS解析器使用标签“Vnew”、“Vold”、“Vind”、“NOV”和“other”按五种不同的行为类型进行分类。这些标签对应于解析程序系统行为类型，如下所示：
Vnew: A DNS resolver that is configured to implement this mechanism and has loaded the nominated key into its local trusted-key stores will respond with an A or AAAA RRset response for the associated "root-key-sentinel-is-ta" queries, SERVFAIL for "root-key-sentinel-not-ta" queries, and SERVFAIL for the signed name queries that return "bogus" validation status.
Vnew：配置为实现此机制并已将指定密钥加载到其本地受信任密钥存储的DNS解析程序将对关联的“根密钥sentinel is ta”查询响应A或AAAA RRset响应，对“根密钥sentinel not ta”查询响应SERVFAIL，对返回“假”的签名名称查询响应SERVFAIL验证状态。
Vold: A DNS resolver that is configured to implement this mechanism and has not loaded the nominated key into its local trusted-key stores will respond with a SERVFAIL for the associated "root-key-sentinel-is-ta" queries, an A or AAAA RRset response for "root-key-sentinel-not-ta" queries, and SERVFAIL for the signed name queries that return "bogus" validation status.
Vold：配置为实现此机制且未将指定密钥加载到其本地受信任密钥存储的DNS解析程序将对关联的“根密钥sentinel is ta”查询响应SERVFAIL，对“根密钥sentinel not ta”查询响应A或AAAA RRset，对返回“假”的签名名称查询响应SERVFAIL验证状态。
Vind: A DNS resolver that is not configured to implement this mechanism will respond with an A or AAAA RRset response for "root-key-sentinel-is-ta", an A or AAAA RRset response for "root-key-sentinel-not-ta", and SERVFAIL for the name that returns "bogus" validation status. This set of responses does not give any information about the trust anchors used by this resolver.
Vind：未配置为实现此机制的DNS解析程序将响应“根密钥sentinel is ta”的A或AAAA RRset响应，“根密钥sentinel not ta”的A或AAAA RRset响应，以及返回“伪”验证状态的名称的SERVFAIL。这组响应不提供有关此冲突解决程序使用的信任锚的任何信息。
nonV: A non-security-aware DNS resolver will respond with an A or AAAA RRset response for "root-key-sentinel-is-ta", an A or AAAA RRset response for "root-key-sentinel-not-ta" and an A or AAAA RRset response for the name that returns "bogus" validation status.
nonV：非安全意识DNS解析程序将对“根密钥sentinel is ta”响应A或AAAA RRset响应，“根密钥sentinel not ta”响应A或AAAA RRset响应，并对返回“伪”验证状态的名称响应A或AAAA RRset响应。
other: There is the potential to admit other combinations of responses to these three queries. While this may appear self-contradictory, there are cases where such an outcome is possible. For example, in DNS resolver farms, what appears to be a single DNS resolver that responds to queries passed to a single IP address is in fact constructed as a collection of slave resolvers, and the query is passed to one of these internal resolver engines. If these individual slave resolvers in the farm do not behave identically, then other sets of results can be expected from these three queries. In such a case, no determination about the capabilities of this DNS resolver farm can be made.
其他：有可能接受对这三个查询的其他组合响应。虽然这可能看起来自相矛盾，但在某些情况下，这样的结果是可能的。例如，在DNS解析程序场中，看似响应传递到单个IP地址的查询的单个DNS解析程序实际上构造为从属解析程序的集合，并且该查询被传递到这些内部解析程序引擎之一。如果服务器场中的这些独立从属冲突解决程序的行为不相同，则可以从这三个查询中获得其他结果集。在这种情况下，无法确定此DNS解析程序场的功能。
Note that SERVFAIL might be cached according to Section 7 of [RFC2308] for up to 5 minutes and a positive answer for up to its TTL.
请注意，根据[RFC2308]的第7节，SERVFAIL可能会被缓存最多5分钟，而其TTL可能会得到肯定的回答。
If a client directs these three queries to a single resolver, the responses should allow the client to determine the capability of the resolver and, if it supports this sentinel mechanism, whether or not it has a particular key in its trust-anchor store, as in the following table:
如果客户端将这三个查询定向到单个冲突解决程序，则响应应允许客户端确定冲突解决程序的功能，如果客户端支持此sentinel机制，则客户端的信任锚存储中是否有特定密钥，如下表所示：
Query
+----------+-----------+------------+
| is-ta | not-ta | bogus |
+-------+----------+-----------+------------+
| Vnew | Y | SERVFAIL | SERVFAIL |
| Vold | SERVFAIL | Y | SERVFAIL |
Type | Vind | Y | Y | SERVFAIL |
| nonV | Y | Y | Y |
| other | * | * | * |
+-------+----------+-----------+------------+
Query
+----------+-----------+------------+
| is-ta | not-ta | bogus |
+-------+----------+-----------+------------+
| Vnew | Y | SERVFAIL | SERVFAIL |
| Vold | SERVFAIL | Y | SERVFAIL |
Type | Vind | Y | Y | SERVFAIL |
| nonV | Y | Y | Y |
| other | * | * | * |
+-------+----------+-----------+------------+
In this table, the "Y" response denotes an A or AAAA RRset response (depending on the query type of A or AAAA records), "SERVFAIL" denotes a DNS SERVFAIL response code (RCODE 2), and "*" denotes either response.
在此表中，“Y”响应表示A或AAAA RRset响应（取决于A或AAAA记录的查询类型），“SERVFAIL”表示DNS SERVFAIL响应代码（RCODE 2），“*”表示任一响应。
Vnew: The nominated key is trusted by the resolver.
Vnew:解析程序信任指定的密钥。
Vold: The nominated key is not yet trusted by the resolver.
Vold:解析程序尚未信任指定的密钥。
Vind: There is no information about the trust anchors of the resolver.
Vind：没有关于冲突解决程序的信任锚的信息。
nonV: The resolver does not perform DNSSEC validation.
NOV：冲突解决程序不执行DNSSEC验证。
other: The properties of the resolver cannot be analyzed by this protocol.
其他：此协议无法分析冲突解决程序的属性。
Some resolvers are configured not to answer queries using the recursive algorithm first described in [RFC1034], Section 4.3.2 but instead relay queries to one or more other resolvers. Resolvers configured in this manner are referred to in this document as "forwarders".
某些解析器配置为不使用[RFC1034]第4.3.2节中首先描述的递归算法回答查询，而是将查询中继到一个或多个其他解析器。以这种方式配置的解析器在本文件中称为“转发器”。
If the resolver is non-validating and has a single forwarder, then it will presumably mirror the capabilities of the forwarder's target resolver.
如果解析器是非验证的，并且只有一个转发器，那么它可能会镜像转发器的目标解析器的功能。
If the validating resolver has a forwarding configuration, and it sets the EDNS(0) Checking Disabled (CD) bit as described in Section 3.2.2 of [RFC4035] on all forwarded queries, then this resolver is acting in a manner that is identical to a standalone resolver.
如果验证冲突解决程序具有转发配置，并且按照[RFC4035]第3.2.2节中所述，在所有转发查询上设置EDNS（0）检查禁用（CD）位，则此冲突解决程序的操作方式与独立冲突解决程序相同。
A more complex case is where all of the following conditions hold:
更复杂的情况是，以下所有条件均成立：
o Both the validating resolver and the forwarder target resolver support this trusted key sentinel mechanism.
o 验证冲突解决程序和转发器目标冲突解决程序都支持这种可信密钥哨兵机制。
o The local resolver's queries do not have the EDNS(0) CD bit set.
o 本地冲突解决程序的查询未设置EDNS（0）CD位。
o The trusted key state differs between the forwarding resolver and the forwarder's target resolver.
o 转发解析程序和转发程序的目标解析程序之间的受信任密钥状态不同。
In such a case, either the outcome is indeterminate validating ("Vind") or there are mixed signals such as SERVFAIL in all three responses ("other"), which is similarly an indeterminate response with respect to the trusted key state.
在这种情况下，要么结果是不确定验证（“Vind”），要么在所有三个响应（“其他”）中都存在混合信号，例如SERVFAIL，这类似于关于受信任密钥状态的不确定响应。
Section 3 describes a trust-anchor test that can be used in the simple situation where the test queries are being passed to a single recursive resolver that directly queries authoritative name servers.
第3节描述了一个信任锚测试，该测试可用于将测试查询传递给直接查询权威名称服务器的单个递归解析器的简单情况。
However, the common end-user scenario is where a user's local DNS resolution environment is configured to use more than one recursive resolver. The single-resolver test technique will not function reliably in such cases, as a SERVFAIL response from one resolver may cause the local stub resolver to repeat the query against one of the other configured resolvers, and the results may be inconclusive.
但是，常见的最终用户场景是将用户的本地DNS解析环境配置为使用多个递归解析器。在这种情况下，单冲突解决程序测试技术将无法可靠地运行，因为来自一个冲突解决程序的SERVFAIL响应可能会导致本地存根冲突解决程序对另一个配置的冲突解决程序重复查询，并且结果可能不确定。
In describing a test procedure that can be used for a set of DNS resolvers, there are some necessary changes to the nature of the question that this test can answer, the assumptions about the behavior of the DNS resolution environment, and some further observations about potential variability in the test outcomes.
在描述可用于一组DNS解析程序的测试过程时，此测试可以回答的问题的性质、有关DNS解析环境行为的假设以及关于测试结果中潜在可变性的一些进一步观察结果都有一些必要的变化。
This test is not intended to expose which trust anchors are used by any single DNS resolver.
此测试无意公开任何单个DNS解析程序使用的信任锚。
The test scenario is explicitly restricted to that of the KSK environment where a current, active KSK (called "KSK-current") is to be replaced with a new KSK (called "KSK-new"). The test is designed to be run between when KSK-new is introduced into the root zone and when the root zone is signed with KSK-new.
测试场景明确限制为KSK环境的场景，其中当前的活动KSK（称为“KSK current”）将被新的KSK（称为“KSK new”）替换。测试设计为在将KSK new引入根区域和根区域使用KSK new签名之间运行。
The objective of the test is to determine if the user will be negatively impacted by the KSK roll. A "negative impact" for the user is defined such that all the configured resolvers are security-aware resolvers that perform validation of DNSSEC-signed responses, and none of these resolvers have loaded KSK-new into their local trust-anchor set. In this situation, it is anticipated that once the KSK is rolled, the entire set of the user's resolvers will not be able to validate the contents of the root zone, and the user is likely to lose DNS service as a result of this inability to perform successful DNSSEC validation.
测试的目的是确定用户是否会受到KSK辊的负面影响。定义了对用户的“负面影响”，以便所有配置的冲突解决程序都是安全感知的冲突解决程序，执行DNSSEC签名响应的验证，并且这些冲突解决程序都没有将KSK new加载到其本地信任锚集中。在这种情况下，预计一旦滚动KSK，整个用户的解析程序集将无法验证根区域的内容，并且由于无法成功执行DNSSEC验证，用户可能会丢失DNS服务。
There are a number of assumptions about the DNS environment used in this test. Where these assumptions do not hold, the results of the test will be indeterminate.
关于本测试中使用的DNS环境，有许多假设。如果这些假设不成立，测试结果将是不确定的。
o When a recursive resolver returns SERVFAIL to the user's stub resolver, the stub resolver will send the same query to the next resolver in the locally configured resolver set. It will continue to do this until it either gets a non-SERVFAIL response or runs out of resolvers to try.
o 当递归解析器将SERVFAIL返回给用户的存根解析器时，存根解析器将向本地配置的解析器集中的下一个解析器发送相同的查询。它将继续执行此操作，直到获得非SERVFAIL响应或用尽可尝试的解析程序。
o When the user's stub resolver passes a query to a resolver in the configured resolver set, it will get a consistent answer over the time frame of the queries. This assumption implies that if the same query is asked by the same stub resolver multiple times in succession to the same recursive resolver, the recursive resolver's response will be the same for each of these queries.
o 当用户的存根解析器将查询传递给配置的解析器集中的解析器时，它将在查询的时间范围内得到一致的答案。这个假设意味着，如果同一个存根解析器连续多次向同一个递归解析器请求同一个查询，那么递归解析器对每个查询的响应都是相同的。
o All DNSSEC-validating resolvers have KSK-current in their local trust-anchor cache.
o 所有DNSSEC验证解析程序在其本地信任锚点缓存中都具有KSK current。
There is no current published measurement data that indicates to what extent the first two assumptions listed here are valid or how many end users may be impacted by these assumptions. In particular, the first assumption, that a consistent SERVFAIL response will cause the
目前没有公布的测量数据表明此处列出的前两个假设在多大程度上有效，或者有多少最终用户可能受到这些假设的影响。特别是第一个假设，即一致的SERVFAIL响应将导致
local stub DNS resolution environment to query all of its configured recursive resolvers before concluding that the name cannot be resolved, is a critical assumption for this test.
本地存根DNS解析环境在断定名称无法解析之前查询其所有配置的递归解析程序，这是本测试的一个关键假设。
Note that additional precision/determinism may be achievable by bypassing the normal OS behavior and explicitly testing using each configured recursive resolver (e.g., using "dig").
请注意，通过绕过正常操作系统行为并使用每个配置的递归解析器（例如，使用“dig”）显式测试，可以实现额外的精度/确定性。
The sentinel detection process tests a DNS resolution environment with three query names. Note that these are the same general categories of query as in Section 3, but the Key Tag used is different for some queries:
sentinel检测过程使用三个查询名称测试DNS解析环境。请注意，这些是与第3节中相同的一般查询类别，但在某些查询中使用的键标记不同：
o A query name that is signed with a DNSSEC signature that cannot be validated (described as a "bogus" RRset in Section 5 of [RFC4033] when, for example, an RRset is not signed with a valid RRSIG record).
o 使用无法验证的DNSSEC签名签名的查询名称（例如，当RRset未使用有效的RRSIG记录签名时，在[RFC4033]第5节中称为“伪”RRset）。
o A query name containing the leftmost label "root-key-sentinel-not-ta-<key-tag-of-KSK-current>". This name MUST be a validly signed name. Any validly signed DNS zone can be used for this test.
o 一个查询名称，其中包含最左边的标签“根密钥sentinel not ta-<key tag of KSK current>”。此名称必须是有效签名的名称。任何有效签名的DNS区域都可用于此测试。
o A query name containing the leftmost label "root-key-sentinel-is-ta-<key-tag-of-KSK-new>". This name MUST be a validly signed name. Any validly signed DNS zone can be used for this test.
o 包含最左边标签“root key sentinel is ta-<key tag of KSK new>”的查询名称。此名称必须是有效签名的名称。任何有效签名的DNS区域都可用于此测试。
The responses received from queries to resolve each of these names can be evaluated to infer a trust key state of the user's DNS resolution environment.
从解析这些名称的查询中收到的响应可以进行评估，以推断用户DNS解析环境的信任密钥状态。
The responses to these queries are described using a simplified notation. Each query will result in either a SERVFAIL response (denoted "S"), indicating that all of the resolvers in the recursive resolver set returned the SERVFAIL response code, or a response with the desired RRset value (denoted "A"). The queries are ordered by the "invalid" name, the "root-key-sentinel-not-ta" label, then the "root-key-sentinel-is-ta" label, and a triplet notation denotes a particular response. For example, the triplet "(S S A)" denotes a SERVFAIL response to the invalid query, a SERVFAIL response to the "root-key-sentinel-not-ta" query, and an RRset response to the "root-key-sentinel-is-ta" query.
对这些查询的响应使用简化的表示法进行描述。每个查询将产生一个SERVFAIL响应（表示为“S”），表示递归解析器集中的所有解析器都返回了SERVFAIL响应代码，或者产生一个具有所需RRset值的响应（表示为“a”）。查询按“无效”名称、“根键哨兵不是ta”标签排序，然后按“根键哨兵是ta”标签排序，三元组表示法表示特定响应。例如，三元组“（sa）”表示对无效查询的SERVFAIL响应、“根密钥sentinel not ta”查询的SERVFAIL响应，以及对“根密钥sentinel is ta”查询的RRset响应。
The set of all possible responses to these three queries are:
对这三个查询的所有可能响应集为：
(A * *): If any resolver returns an "A" response for the query for the invalid name, then the resolver set contains at least one non-validating DNS resolver, and the user will not be impacted by the KSK roll.
（A**）：如果任何解析程序对无效名称的查询返回“A”响应，则解析程序集至少包含一个非验证DNS解析程序，并且用户不会受到KSK滚动的影响。
(S A *): If any of the resolvers returns an "A" response for the "root-key-sentinel-not-ta" query, then at least one of the resolvers does not recognize the sentinel mechanism, and the behavior of the collection of resolvers during the KSK roll cannot be reliably determined.
（S A*）：如果任何冲突解决程序对“根密钥sentinel not ta”查询返回“A”响应，则至少有一个冲突解决程序无法识别sentinel机制，并且无法可靠地确定KSK滚动期间冲突解决程序集合的行为。
(S S A): This case implies that all of the resolvers in the set perform DNSSEC validation, all of the resolvers are aware of the sentinel mechanism, and at least one resolver has loaded KSK-new as a local trust anchor. The user will not be impacted by the KSK roll.
（SA）：这种情况意味着集合中的所有冲突解决程序都执行DNSSEC验证，所有冲突解决程序都知道sentinel机制，并且至少有一个冲突解决程序已将KSK new加载为本地信任锚。用户不会受到KSK滚动的影响。
(S S S): This case implies that all of the resolvers in the set perform DNSSEC validation, all of the resolvers are aware of the sentinel mechanism, and none of the resolvers has loaded KSK-new as a local trust anchor. The user will be negatively impacted by the KSK roll.
（S）：这种情况意味着集合中的所有冲突解决程序都执行DNSSEC验证，所有冲突解决程序都知道sentinel机制，并且没有一个冲突解决程序将KSK new加载为本地信任锚。用户将受到KSK滚动的负面影响。
This document describes a mechanism for allowing users to determine the trust-anchor state of root zone key signing keys in the DNS resolution system that they use. If the user executes third-party code, then this information may also be available to the third party.
本文档描述了一种允许用户确定其使用的DNS解析系统中根区域密钥签名密钥的信任锚状态的机制。如果用户执行第三方代码，则该信息也可供第三方使用。
The mechanism does not require resolvers to set otherwise-unauthenticated responses to be marked as authenticated and does not alter the security properties of DNSSEC with respect to the interpretation of the authenticity of responses that are so marked.
该机制不要求解析程序将其他未经验证的响应设置为标记为已验证，也不改变DNSSEC在解释如此标记的响应的真实性方面的安全属性。
The mechanism does not require any further significant processing of DNS responses, and queries of the form described in this document do not impose any additional load that could be exploited in an attack over the normal DNSSEC-validation processing load.
该机制不需要对DNS响应进行任何进一步的重要处理，并且本文档中描述的形式的查询不会对正常DNSSEC验证处理负载施加可能在攻击中被利用的任何额外负载。
The mechanism in this document enables third parties (with either good or bad intentions) to learn something about the security configuration of recursive DNS resolvers. That is, someone who can cause an Internet user to make specific DNS queries (e.g., via web-based advertisements or JavaScript in web pages) can, under certain specific circumstances that include additional knowledge of the resolvers that are invoked by the user, determine which trust anchors are configured in these resolvers. Without this additional knowledge, the third party can infer the aggregate capabilities of the user's DNS resolution environment but cannot necessarily infer the trust configuration of any recursive name server.
本文档中的机制使第三方（无论出于好意还是恶意）能够了解递归DNS解析程序的安全配置。也就是说，可以使互联网用户进行特定DNS查询（例如，通过基于web的广告或网页中的JavaScript）的人可以在某些特定情况下，包括用户调用的解析程序的附加知识，确定在这些解析程序中配置了哪些信任锚。没有这些额外的知识，第三方可以推断用户的DNS解析环境的聚合能力，但不一定能够推断任何递归名称服务器的信任配置。
This document has no IANA actions.
本文档没有IANA操作。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.
[RFC2308]Andrews，M.“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，DOI 10.17487/RFC2308，1998年3月<https://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, <https://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月<https://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, <https://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月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC5011]StJohns，M.“DNS安全（DNSSEC）信任锚的自动更新”，STD 74，RFC 5011，DOI 10.17487/RFC5011，2007年9月<https://www.rfc-editor.org/info/rfc5011>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<https://www.rfc-editor.org/info/rfc7719>.
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.
[RFC8145]Wessels，D.，Kumari，W.和P.Hoffman，“DNS安全扩展（DNSSEC）中的信令信任锚知识”，RFC8145DOI 10.17487/RFC81452017年4月<https://www.rfc-editor.org/info/rfc8145>.
This appendix provides a non-normative example of how the sentinel mechanism could be used and what each participant does. It is provided in a conversational tone to be easier to follow. The examples here all assume that each person has just one resolver or a system of resolvers that have the same properties.
本附录提供了一个非规范性示例，说明如何使用哨兵机制以及每个参与者的行为。它以对话的语气提供，以便更容易理解。这里的示例都假设每个人只有一个解析器或一个具有相同属性的解析器系统。
Alice is in charge of the DNS root KSK (Key Signing Key) and would like to roll/replace the key with a new one. She publishes the new KSK but would like to be able to predict/measure what the impact will be before removing/revoking the old key. The current KSK has a Key Tag of 11112; the new KSK has a Key Tag of 02323. Users want to verify that their resolver will not break after Alice rolls the root KSK (that is, starts signing with just the KSK whose Key Tag is 02323).
Alice负责DNS根KSK（密钥签名密钥），并希望使用新密钥滚动/替换密钥。她发布了新的KSK，但希望能够在删除/撤销旧密钥之前预测/衡量其影响。当前KSK的密钥标签为11112；新KSK的密钥标签为02323。用户希望验证在Alice滚动根KSK（即，仅使用密钥标记为02323的KSK开始签名）后，他们的解析器不会中断。
Bob, Charlie, Dave, and Ed are all users. They use the DNS recursive resolvers supplied by their ISPs. They would like to confirm that their ISPs have picked up the new KSK. Bob's ISP does not perform validation. Charlie's ISP does validate, but the resolvers have not yet been upgraded to support this mechanism. Dave and Ed's resolvers have been upgraded to support this mechanism; Dave's resolver has the new KSK, but Ed's resolver hasn't managed to install the 02323 KSK in its trust store yet.
Bob、Charlie、Dave和Ed都是用户。他们使用ISP提供的DNS递归解析器。他们想确认他们的ISP已经收到了新的KSK。Bob的ISP不执行验证。Charlie的ISP确实进行了验证，但解析程序尚未升级以支持此机制。Dave和Ed的解析器已升级以支持此机制；Dave的解析器拥有新的KSK，但Ed的解析器尚未在其信任存储中安装02323 KSK。
Geoff is a researcher. He would like to both provide a means for Bob, Charlie, Dave, and Ed to perform tests and himself be able to perform Internet-wide measurements of what the impact will be (and report this back to Alice).
杰夫是一名研究员。他希望为Bob、Charlie、Dave和Ed提供一种方法来执行测试，并且他自己能够执行互联网范围内的影响测量（并将此报告给Alice）。
Geoff sets an authoritative DNS server for example.com and also a web server (www.example.com). He adds three address records to example.com:
Geoff为example.com设置了一个权威DNS服务器，还设置了一个web服务器（www.example.com）。他在example.com中添加了三个地址记录：
bogus.example.com. IN AAAA 2001:db8::1
bogus.example.com. IN AAAA 2001:db8::1
root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1
root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1
Note that the use of "example.com" names and the addresses here are examples, and "bogus" intentionally has invalid DNSSEC signatures. In a real deployment, the domain names need to be under the control of the researcher, and the addresses must be real, reachable addresses.
请注意，此处使用的“example.com”名称和地址都是示例，“伪造”故意具有无效的DNSSEC签名。在实际部署中，域名需要在研究人员的控制下，并且地址必须是真实的、可访问的地址。
Geoff then DNSSEC signs the example.com zone and intentionally makes the bogus.example.com record have bogus validation status (for example, by editing the signed zone and entering garbage for the signature). Geoff also configures his web server to listen on 2001:db8::1 and serve a resource (for example, a 1x1 GIF, 1x1.gif) for all of these names. The web server also serves a web page (www.example.com) that contains links to these three resources (http://bogus.example.com/1x1.gif, http://root-key-sentinel-is-ta-02323.example.com/1x1.gif, and http://root-key-sentinel-not-ta-11112.example.com/1x1.gif).
然后，Geoff DNSSEC对example.com区域进行签名，并故意使bogus.example.com记录具有虚假验证状态（例如，通过编辑签名区域并输入垃圾进行签名）。Geoff还将其web服务器配置为侦听2001:db8:：1，并为所有这些名称提供一个资源（例如，1x1 GIF、1x1.GIF）。web服务器还提供一个网页（www.example.com），其中包含指向这三个资源的链接(http://bogus.example.com/1x1.gif, http://root-key-sentinel-is-ta-02323.example.com/1x1.gif和http://root-key-sentinel-not-ta-11112.example.com/1x1.gif).
Geoff then asks Bob, Charlie, Dave, and Ed to browse to www.example.com. Using the methods described in this document, the users can figure out what their fate will be when the 11112 KSK is removed.
然后，杰夫请鲍勃、查理、戴夫和埃德浏览www.example.com。使用本文档中描述的方法，用户可以了解当11112 KSK被移除时他们的命运。
Bob is not using a validating resolver. This means that he will be able to resolve bogus.example.com (and fetch the 1x1 GIF); this tells him that the KSK roll does not affect him, and so he will be OK.
Bob未使用验证解析程序。这意味着他将能够解析bogus.example.com（并获取1x1 GIF）；这告诉他KSK掷骰不会影响他，所以他会没事的。
Charlie's resolvers are validating, but they have not been upgraded to support the KSK sentinel mechanism. Charlie will not be able to fetch the http://bogus.example.com/1x1.gif resource (the bogus.example.com record is bogus, and none of his resolvers will resolve it). He is able to fetch both of the other resources; from this, he knows (see the logic in the body of this document) that he is using validating resolvers but that at least one of these resolvers is not configured to perform sentinel processing. The KSK sentinel method cannot provide him with a definitive answer to the question of whether he will be impacted by the KSK roll.
Charlie的解析器正在验证，但尚未升级以支持KSK sentinel机制。查理将无法取回那封信http://bogus.example.com/1x1.gif 资源（bogus.example.com记录是假的，他的解析程序都不会解析它）。他能够获取其他两种资源；由此，他知道（参见本文档正文中的逻辑）他正在使用验证解析器，但这些解析器中至少有一个未配置为执行sentinel处理。KSK sentinel方法无法为他提供关于他是否会受到KSK名单影响的明确答案。
Dave's resolvers implement the sentinel method and have picked up the new KSK. For the same reason as Charlie, he cannot fetch the "bogus" resource. His resolver resolves the root-key-sentinel-is-ta-02323.example.com name normally (it contacts the example.com authoritative servers, etc.); as it supports the sentinel mechanism, just before Dave's recursive resolver sends the reply to Dave's stub, it performs the KSK sentinel check. The QNAME starts with "root-key-sentinel-is-ta-", and the recursive resolver does indeed have a key with the Key Tag of 02323 in its root trust store. This means that this part of the KSK sentinel check passes (it is true that Key Tag 02323 is in the trust-anchor store), and the recursive resolver replies normally (with the answer provided by the authoritative server). Dave's recursive resolver then resolves the root-key-sentinel-not-ta-11112.example.com name. Once again, it performs the normal resolution process, but because it implements KSK sentinel (and the QNAME starts with "root-key-sentinel-not-ta-"), just before sending the reply, it performs the KSK sentinel check. As it has the
Dave的解析器实现了sentinel方法，并获得了新的KSK。出于与查理相同的原因，他无法获取“伪造”资源。他的解析器正常解析root-key-sentinel-is-ta-02323.example.com名称（它会联系example.com权威服务器等）；由于它支持sentinel机制，在Dave的递归解析器将应答发送到Dave的存根之前，它执行KSK sentinel检查。QNAME以“root key sentinel is ta-”开头，递归解析器的根信任存储中确实有一个key标签为02323的密钥。这意味着KSK sentinel检查的这一部分通过（密钥标记02323确实在信任锚存储中），递归解析器正常应答（由权威服务器提供应答）。Dave的递归解析器然后解析root-key-sentinel-not-ta-11112.example.com名称。同样，它执行正常的解析过程，但是因为它实现了KSK sentinel（并且QNAME以“root key sentinel not ta-”开头），所以就在发送回复之前，它执行KSK sentinel检查。因为它有
key with key-tag 11112 in its trust-anchor store, the answer to "is this *not* a trust anchor" is false, and so the recursive resolver does not reply with the answer from the authoritative server. Instead, it replies with a SERVFAIL (note that replying with SERVFAIL instead of the original answer is the only mechanism that KSK Sentinel uses). This means that Dave cannot fetch "bogus", he can fetch "root-key-sentinel-is-ta-02323", but he cannot fetch "root-key-sentinel-not-ta-11112". From this, Dave knows that he is behind a collection of resolvers that all validate, all have the key with Key Tag 11112 loaded, and at least one of these resolvers has loaded the key with Key Tag 02323 into its local trust-anchor cache. Dave will not be impacted by the KSK roll.
密钥标记为11112的密钥在其信任锚点存储中，对“Isthis*not*a trust anchor”的回答为false，因此递归解析器不会使用权威服务器的回答进行回复。相反，它使用SERVFAIL进行回复（请注意，使用SERVFAIL而不是原始答案进行回复是KSK Sentinel使用的唯一机制）。这意味着Dave无法获取“伪造”，他可以获取“root-key-sentinel-is-ta-02323”，但他无法获取“root-key-sentinel-not-ta-11112”。从这一点上，Dave知道他在一组解析程序后面，这些解析程序都进行了验证，都加载了密钥标签为11112的密钥，并且至少有一个解析程序已将密钥标签为02323的密钥加载到其本地信任锚缓存中。Dave不会受到KSK滚动的影响。
Just like Charlie and Dave, Ed cannot fetch the "bogus" record. This tells him that his resolvers are validating. When his (sentinel-aware) resolvers perform the KSK sentinel check for "root-key-sentinel-is-ta-02323", none of them have loaded the new key with Key Tag 02323 in their local trust-anchor store. This means the check fails, and Ed's recursive resolver converts the (valid) answer into a SERVFAIL error response. It performs the same check for root-key-sentinel-not-ta-11112.example.com, and as all of Ed's resolvers both perform DNSSEC validation and recognize the sentinel label, Ed will be unable to fetch the "root-key-sentinel-not-ta-11112" resource. This tells Ed that his resolvers have not installed the new KSK and he will be negatively impacted by the KSK roll.
就像查理和戴夫一样，艾德也拿不到那张“假”唱片。这告诉他，他的解析器正在验证。当his（sentinel aware）解析程序对“root-key-sentinel-is-ta-02323”执行KSK sentinel检查时，它们都没有在本地信任锚存储中加载密钥标签为02323的新密钥。这意味着检查失败，Ed的递归解析器将（有效）答案转换为SERVFAIL错误响应。它对root-key-sentinel-not-ta-11112.example.com执行相同的检查，由于Ed的所有解析器都执行DNSSEC验证并识别sentinel标签，因此Ed将无法获取“root-key-sentinel-not-ta-11112”资源。这告诉Ed，他的解析器尚未安装新的KSK，他将受到KSK辊的负面影响。
Geoff would like to do a large-scale test and provide the information back to Alice. He uses some mechanism such as causing users to go to a web page to cause a large number of users to attempt to resolve the three resources, and he then analyzes the results of the tests to determine what percentage of users will be affected by the KSK rollover event.
杰夫想做一个大规模的测试，并将信息反馈给爱丽丝。他使用了一些机制，比如让用户转到一个网页，让大量用户尝试解析这三种资源，然后分析测试结果，以确定KSK翻转事件将影响的用户百分比。
This description is a simplified example. It is not anticipated that Bob, Charlie, Dave, and Ed will actually look for the absence or presence of web resources; instead, the web page that they load would likely contain JavaScript (or similar) that displays the result of the tests, sends the results to Geoff, or both. This sentinel mechanism does not rely on the web: it can equally be used by trying to resolve the names (for example, using the common "dig" command) and checking which names result in a SERVFAIL.
此描述是一个简化的示例。预计Bob、Charlie、Dave和Ed不会实际查找web资源的缺失或存在；相反，他们加载的网页可能会包含JavaScript（或类似内容），用于显示测试结果、将结果发送给Geoff或两者兼而有之。这种sentinel机制不依赖于web：它同样可以通过尝试解析名称（例如，使用通用的“dig”命令）和检查哪些名称导致SERVFAIL来使用。
Acknowledgements
致谢
This document has borrowed extensively from [RFC8145] for the introductory text, and the authors would like to acknowledge and thank the authors of that document both for some text excerpts and for the more general stimulation of thoughts about monitoring the progress of a roll of the KSK of the root zone of the DNS.
本文件从[RFC8145]中广泛借用了介绍性文本，作者要感谢该文件的作者，感谢他们提供了一些文本摘录，并对监控DNS根区域KSK卷的进度提出了更普遍的想法。
The authors would like to thank Joe Abley, Mehmet Akcin, Mark Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis, George Michaelson, Benno Overeinder, Matthew Pounsett, Hugo Salgado-Hernandez, Andreas Schulze, Mukund Sivaraman, Petr Spacek, Job Snijders, Andrew Sullivan, Ondrej Sury, Paul Vixie, Duane Wessels, and Paul Wouters for their helpful feedback.
作者要感谢乔·艾布利、默米特·阿克辛、马克·安德鲁斯、理查德·巴恩斯、雷·贝利斯、斯蒂芬·博茨迈耶、大卫·康拉德、拉尔夫·多尔曼、约翰·迪金森、施泰纳·豪格、鲍勃·哈罗德、韦斯·哈达克、保罗·霍夫曼、马特·拉森、金美·塔图亚、爱德华·刘易斯、乔治·迈克尔森、本诺·奥弗林德、马修·庞塞特、雨果·萨尔加多·埃尔南德斯、，Andreas Schulze、Mukund Sivaraman、Petr Spacek、Job Snijders、Andrew Sullivan、Ondrej Sury、Paul Vixie、Duane Wessels和Paul Wouters感谢他们的有益反馈。
The authors would like to especially call out Paul Hoffman and Duane Wessels for providing comments in the form of pull requests. Joe Abley also helpfully provided extensive review and OLD / NEW text.
作者希望特别呼吁Paul Hoffman和Duane Wessels以请求的形式提供评论。Joe Abley还提供了广泛的评论和新旧文本。
Petr Spacek wrote some very early implementations and provided significant feedback -- including pointing out when the test bed didn't match the document!
Petr Spacek编写了一些非常早期的实现，并提供了重要的反馈——包括指出测试台何时与文档不匹配！
Authors' Addresses
作者地址
Geoff Huston
Email: gih@apnic.net
URI: http://www.apnic.net
Geoff Huston
Email: gih@apnic.net
URI: http://www.apnic.net
Joao Silva Damas
Email: joao@apnic.net
URI: http://www.apnic.net
Joao Silva Damas
Email: joao@apnic.net
URI: http://www.apnic.net
Warren Kumari Email: warren@kumari.net
Warren Kumari电子邮件：warren@kumari.net