DNS安全扩展（DNSSEC）是为了通过数字签名为DNS数据提供源身份验证和完整性保护而开发的。这些数字签名可以通过建立一个信任链来验证，该信任链从信任锚开始，一直到DNS中的特定节点。本文档指定了一种机制，允许最终用户和第三方确定处理该用户DNS查询的解析程序根密钥的受信任密钥状态。注意，此方法仅适用于确定哪些密钥在根密钥的信任存储区中。
Introduction DNS安全扩展（DNSSEC）[RFC4033]、[RFC4034]和[RFC4035]是为了通过使用数字签名为DNS数据提供源身份验证和完整性保护而开发的。DNSSEC使用密钥标记将签名与生成它们的密钥有效匹配。密钥标记是根据DNSKEY资源记录（RR）的RDATA计算的16位值，如[RFC4034]的附录B所述。RRSIG RRs包含一个密钥标记字段，其值等于用于生成相应签名的DNSKEY RR的密钥标记。本文档说明了执行响应验证的具有安全意识的DNS解析器如何以某种方式响应某些查询，该方式允许执行查询的代理推断出根的特定密钥是否已加载到该解析器的受信任密钥存储区中。 本文档还描述了一个过程，在该过程中可以测试一组解析器，以确定这些解析器中的至少一个是否已将给定密钥加载到其受信任密钥存储中。 这些测试可用于确定某个根区域密钥签名密钥（KSK）是否已准备好在计划的根区域KSK roll上下文中用作受信任密钥。
两个主要用例：
o用户可能希望确定其DNS解析环境的解析器是否已准备好进行即将到来的根KSK轮转更新。 o研究人员希望在互联网范围内对即将到来的根KSK轮转对用户造成负面影响的比例进行研究。
本文档中描述的机制满足这两个用例的需求。这个机制对于实现和使用是可选的。如果实现了这一机制，则默认情况下应启用该机制，以便于在互联网范围内进行测量。由于本地策略的原因，可以提供配置选项来禁用该机制。
本文档中描述的KSK sentinel测试使用一个测试，该测试包含对最左边标签具有特殊值的域名的一组DNS查询。该测试依赖于支持在查询中识别此特殊名称模式的机制的递归解析器；在某些定义的情况下，它将返回DNS SERVFAIL响应代码（RCODE 2），模拟DNSSEC验证失败时安全感知解析器返回的响应代码。
如果浏览器或操作系统配置了多个解析器，并且这些解析器具有不同的属性（例如，一个执行DNSSEC验证，另一个不执行），则仍可以使用本文档中描述的sentinel测试。sentinel测试对DNS解析行为进行了许多假设，这些假设不一定适用于所有环境；如果这些假设不适用，则此测试可能会产生不确定或不一致的结果。例如，如果在收到SERVFAIL响应代码时需要存根解析器查询本地配置集中的下一个递归解析器，则可能会发生这种情况。在这些假设不成立的某些情况下，重复相同的测试查询集可能会生成不同的结果。
注意，本文件中描述的机制所促进的测量与[RFC8145]的测量不同。RFC 8145依赖于向根服务器报告根区域的本地缓存信任锚的列表的解析器。这些报告可用于推断一个KSK roll可能会影响多少个解析器，但不能推断KSK roll的用户影响是什么。
Sentinel Mechanism in Resolvers 实现此机制的DNSSEC验证解析器必须根据DNSSEC响应验证规范[RFC4035]执行响应验证。此哨兵机制使用两个特殊标签： o root-key-sentinel-is-ta-
o root-key-sentinel-not-ta-
当接收到来自权威服务器的响应时，这些标签将在验证DNS解析程序中触发特殊处理。包含“root-key-sentinel-is-ta-”的标签用于回答以下问题：“这是验证DNS解析程序当前信任的密钥作为信任锚的密钥标记吗？” 包含“root-key-sentinel-not-ta-”的标签用于回答以下问题：“这是验证DNS解析程序当前不信任的密钥作为信任锚的密钥标记吗？”
这里定义的特殊标签是在IETF根据解析器内的期待的行为（第2.1节和第2.2节）和应用的测试方法（第4.3节）对替代模式和方法进行广泛评估后选择的。例如，下划线前缀名称被拒绝，因为某些浏览器和操作系统无法获取它们，因为它们是域名，但不是有效的主机名（请参阅[RFC7719]了解这些定义）。考虑了本地冲突和保留域名最左边的标签，以及对区域操作员的影响，这些操作员可能希望将类似构造的主机名用于此处记录之外的其他用途。因此，必须指出，以这种方式保留标签绝对不被视为“最佳做法”。
2.1. Preconditions o The DNS response is DNSSEC validated.
o The result of validation is “Secure”.
o The Extension Mechanisms for DNS (EDNS(0)) Checking Disabled (CD) bit in the query is not set.
o The QTYPE is either A or AAAA (Query Type value 1 or 28).
o The OPCODE is QUERY.
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-” or “root-key-sentinel-not-ta-”. 注意，在DNS标签中被指定为无符号十进制整数（如[RFC4034]第5.3节中所述），但它是零填充到五位的（例如，42的密钥标签值将在标签中表示为00042）。应严格遵守上述特殊标签的精确规范。例如，一个标签不包含一个填充到五位数的零键标签，这与本规范不匹配，不应该像处理过一样处理——换言之，此类查询应该作为任何其他标签处理，而不是按照第2.2节处理。
2.2. Special Processing 满足第2.1节中所有前提条件的响应需要特殊处理，具体取决于QNAME中最左边的标签。
首先，解析器确定的数值是否等于当前受本地解析器信任并存储在其受信任密钥存储中的活动根区域KSK的任何密钥标记值。活动根区域KSK是当前可用于验证的区域（即，不处于AddPend或revocated状态的密钥，如[RFC5011]中所述）。
其次，解析器根据最左边的标签和信任锚存储中存在具有给定密钥标记的密钥来改变发送到原始查询的响应。对应键的两个标签和两个可能状态生成四个可能的组合，总结如下：
指令“return SERVFAIL”表示解析器必须设置RCODE=SERVFAIL（值2），DNS响应的应答部分必须为空，忽略指定应答部分内容的所有其他文档。
指令“return original answer”意味着解析器必须在不进行任何进一步特殊处理的情况下处理查询，也就是说，就好像本文档中描述的机制没有实现或被禁用一样。A或AAAA查询的答案将发送到客户端。
Sentinel Tests for a Single DNS Resolver 本节描述对单个DNS递归解析器使用sentinel检测机制，以确定此解析器是否使用特定的信任锚来验证DNSSEC签名的响应。请注意，本节中的测试适用于单个DNS解析器。第4节中描述的测试适用于DNS解析器的集合，这可能在最终用户环境的DNS配置中找到。
此机制中使用的DNS名称的关键方面是，它们包含正测试或负测试的指定标签，作为查询名称中最左边的标签。
Sentinel检测过程可以使用三个查询来测试DNS解析器： o A query name containing the leftmost label “root-key-sentinel-is- ta-”. 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 A query name containing the leftmost label “root-key-sentinel-not- ta-”. This also corresponds to a validly signed name. Any validly signed DNS zone can be used as the parent zone for this test.
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).
可以计算从解析每个查询名称的查询接收到的响应，以推断DNS解析程序的信任密钥状态。
这里的一个基本假设是，此技术依赖于安全感知（DNSSEC验证）解析器，该解析器使用SERVFAIL响应代码响应,请求DNSSEC检查,但无法验证响应的查询。注意，其他问题也可能导致解析器返回SERVFAIL响应，因此sentinel处理有时可能导致不正确或不确定的结论。
为了描述此分类过程，DNS解析器使用以下五个不同的行为类型进行分类：“ Vnew”，“ Vold”，“ Vind”，“ nonV”和“ 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.
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.
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.
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.
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.
请注意，SERVFAIL可能会根据[RFC2308]的第7节被缓存5分钟，并对其TTL给出肯定的回答。
如果客户端将这三个查询定向到单个解析器，则响应应允许客户端确定解析器的功能，如果客户端支持此sentinel机制，则应允许客户端确定其信任锚存储中是否具有特定密钥，如下表所示：
在此表中，“Y”响应表示A或AAAA RRset响应（取决于A或AAAA记录的查询类型），“SERVFAIL”表示DNS SERVFAIL响应代码（RCODE 2），“*”表示任一响应。
Vnew: The nominated key is trusted by the resolver.
Vold: The nominated key is not yet trusted by the resolver.
Vind: There is no information about the trust anchors of the resolver.
nonV: The resolver does not perform DNSSEC validation.
other: The properties of the resolver cannot be analyzed by this protocol.
3.1. Forwarders 一些解析器配置为不使用[RFC1034]第4.3.2节中首先描述的递归算法来应答查询，而是将查询中继到一个或多个其他解析器。以这种方式配置的解析器在本文档中称为“转发器forwarders”。
如果解析程序没有验证并且只有一个转发器，那么它可能会镜像转发器的目标解析程序的功能。
如果验证解析器具有转发配置，并且它对所有转发查询设置了[RFC4035]第3.2.2节中所述的EDNS（0）Checking Disabled（CD）位，则此解析器的工作方式与独立解析器相同。
满足以下所有条件的情况更为复杂： o Both the validating resolver and the forwarder target resolver support this trusted key sentinel mechanism.
o The local resolver’s queries do not have the EDNS(0) CD bit set.
o The trusted key state differs between the forwarding resolver and the forwarder’s target resolver.
在这种情况下，要么结果是不确定验证（“Vind”），要么在所有三个响应（“other”）中都存在SERVFAIL之类的混合信号，这类似于对受信任密钥状态的不确定响应。
Sentinel Tests for Multiple Resolvers 第3节描述了一个信任锚测试，该测试可用于将测试查询传递给直接查询权威名称服务器的单个递归解析器的简单情况。但是，常见的最终用户场景是，用户的本地DNS解析环境配置为使用多个递归解析器。在这种情况下，单一解析器测试技术将不能可靠地工作，因为来自一个解析器的SERVFAIL响应可能会导致本地存根解析器对其他配置的解析器之一重复查询，并且结果可能不确定。
在描述可用于一组DNS解析程序的测试过程时，此测试可以回答的问题的性质、DNS解析环境行为的假设以及测试结果中潜在可变性的一些进一步观察都有一些必要的更改。
4.1. Test Scenario and Objective 此测试无意公开任何单个DNS解析程序使用哪些信任锚。
测试场景明确限制为KSK环境的场景，其中当前的活动KSK（称为“KSK current”）将替换为新的KSK（称为“KSK new”）。测试设计为在将KSK new引入根区域和根区域已经使用KSK new签名之间运行。
测试的目的是确定用户是否会受到KSK辊的负面影响。定义了对用户的“负面影响”，以便所有配置的解析器都是安全感知的解析器，它们执行DNSSEC签名响应的验证，并且这些解析器都没有将KSK new加载到其本地信任锚集中。在这种情况下，预计一旦KSK被滚动，整个用户的解析程序集将无法验证根区域的内容，并且用户很可能由于无法成功执行DNSSEC验证而丢失DNS服务。
测试的目的是确定用户是否会受到KSK滚动的负面影响。定义了对用户的“负面影响”，以便所有配置的解析器都是安全感知的解析器，它们执行DNSSEC签名响应的验证，并且这些解析器都没有将KSK new加载到其本地信任锚集中。
在这种情况下，预计一旦KSK被滚动，整个用户的解析程序集将无法验证根区域的内容，并且用户很可能由于无法成功执行DNSSEC验证而丢失DNS服务。
4.2. Test Assumptions 关于此测试中使用的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 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 All DNSSEC-validating resolvers have KSK-current in their local trust-anchor cache.
目前没有公布的测量数据表明此处列出的前两个假设在多大程度上是有效的，或者有多少最终用户可能受到这些假设的影响。特别是，第一个假设是，一致的SERVFAIL响应将导致本地存根DNS解析环境在断定名称无法解析之前查询其所有配置的递归解析器，这是此测试的一个关键假设。
注意，可以通过绕过正常的操作系统行为并使用每个配置的递归解析器显式测试（例如，使用“dig”）来实现额外的精度/确定性。
4.2. Test Procedure sentinel检测过程使用三个查询名称测试DNS解析环境。请注意，这些查询的一般类别与第3节中的相同，但对于某些查询，使用的 Key Tag 不同：
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 A query name containing the leftmost label “root-key-sentinel-not- ta-”. This name MUST be a validly signed name. Any validly signed DNS zone can be used for this test.
o A query name containing the leftmost label “root-key-sentinel-is- ta-”. This name MUST be a validly signed name. Any validly signed DNS zone can be used for this test.
可以计算从解析每个名称的查询接收的响应，以推断用户的DNS解析环境的信任密钥状态。
对这些查询的响应使用简化的表示法进行描述。每个查询都将产生一个SERVFAIL响应（表示为“S”），指示递归解析器集中的所有解析器都返回SERVFAIL响应代码，或者返回一个具有所需RRset值的响应（表示为“a”）。查询按“无效”名称、“根密钥sentinel not ta”标签排序，然后按“根密钥sentinel is ta”标签排序，三元组表示法表示特定的响应。例如，三元组“（S A）”表示对无效查询的SERVFAIL响应，对“根密钥sentinel not ta”查询的SERVFAIL响应，以及对“根密钥sentinel is ta”查询的RRset响应。
对这三个查询的所有可能响应的集合是： (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.
(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 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.
(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.
Security Considerations 本文档描述了一种允许用户确定其使用的DNS解析系统中根区域密钥签名密钥的信任锚定状态的机制。如果用户执行第三方代码，则该信息也可供第三方使用。该机制不要求解析器设置其他未经身份验证的响应，并将其标记为已验证，也不改变DNSSEC在解释如此标记的响应的真实性方面的安全属性。
该机制不需要对DNS响应进行任何进一步的重要处理，并且对本文档中描述的表单的查询不会对正常DNSSEC验证处理负载施加任何可能在攻击中被利用的额外负载。
Privacy Considerations 本文档中的机制使第三方（无论是善意的还是恶意的）能够了解递归DNS解析器的安全配置。也就是说，可以使Internet用户进行特定DNS查询的人（例如，通过基于web的广告或网页中的JavaScript）可以在某些特定情况下（包括用户调用的解析程序的附加知识）确定在这些解析程序中配置了哪些信任锚定。没有这些额外的知识，第三方可以推断用户DNS解析环境的聚合功能，但不一定推断任何递归名称服务器的信任配置。