主页 / server / 问题 / 1079817
Accepted
Tenders McChiken
Asked: 2021-10-07 22:37:13 +0800 CST

如果解析器遇到它不支持的 DNSSEC 算法会怎样？

  • 772

它是拒绝返回请求的记录，还是返回记录，将域视为不安全？

domain-name-system dnssec

2 个回答

  1. Best Answer

    如果解析器遇到它不支持的 DNSSEC 算法会怎样？

    只要存在一个验证路径，DNSSEC 就允许验证。如果解析器能够找出它支持的至少一种算法并检查一切（签名等）是否正常，则 DNSSEC 验证将正常，未知算法将被忽略。

    当然，如果解析器只找到它不支持的算法，甚至没有找到它支持的算法，那么 DNSSEC 验证将失败并被SERVFAIL返回。

    请参阅RFC 4035 的 §5.3.1：

    可能有多个 DNSKEY RR 匹配上述条件。在这种情况下，验证器无法预先确定使用哪个 DNSKEY RR 来验证签名，并且它必须尝试每个匹配的 DNSKEY RR，直到签名被验证或验证器已用完匹配的公钥来尝试。

    所以一个好的算法就足够了，解析器不必测试所有的算法。能够在发布端逐步引入新算法，同时更新解析器以了解新算法，这很好。

    另请参阅 RFC 8626“DNSSEC 的算法实施要求和使用指南”。

    它是拒绝返回请求的记录还是返回记录，将域视为不安全？

    DNSSEC 通常是二进制的：域具有正确的 DNSSEC 验证或错误（因此SERVFAIL）。如果解析器失败，则不允许解析器从域中删除 DNSSEC，并返回记录，就好像该域从一开始就没有 DNSSEC。

    然而，这就是理论。在实践中，递归解析器有时需要继续回答，即使是已知 DNSSEC 损坏的域，也确实会发生这种情况，因为它被认为会造成太大的负担。参见过去著名的 NASA/Comcast 示例。这就是为什么现在有“负信任锚”或 NTA 的原因：这是递归解析器的运营商说“域 X 的 DNSSEC 损坏，忽略那里的失败信任并像没有 DNSSEC 一样运行”的一种方式。它应该是一种临时措施，显然对于每个递归解析器都是本地的。

    请参阅RFC 7646“DNSSEC 负信任锚的定义和使用”（2015 年 9 月）：

    本文档定义了负信任锚 (NTA)，可用于通过在指定域禁用 DNSSEC 验证来缓解 DNSSEC 验证失败。

    • 1

  2. AFAIK 具有安全意识的验证解析器必须给出错误响应。所以期待一个 SERVFAIL 错误响应。

    当更新以支持相对较新的 RFC 8914时，甚至会出现扩展的 DNS 错误详细信息，例如：

     Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
 Extended DNS Error Code 2 - Unsupported DS Digest Type
    • 0

相关问题