如何查看域是否使用DNSSEC

Question

我正试图找到一种方法来查看域是否正在使用DNSSEC.从这个线程:我如何检查域是否使用DNSSEC？我了解到了

dig +dnssec <domain> dnskey

可以揭示很多东西.但经过一些实验,我意识到它只显示名称服务器是否设置了DNSSEC.我需要弄清楚的是,该域名是否标记为在NIC上使用DNSSEC.

我尝试查看python的dnssec 实现,但它们似乎都在查看名称服务器而不是原始的NICzone.

在挖掘之后,我注意到一些NICS(例如sidnl.nl)在WHOIS数据中记录了它,但由于这几乎不可靠(并非所有NICS都这样做),我正在寻找更好的方法.

激光器不必是编程/使用代码片段,但如果是,我会很高兴,如果它是python/C#/ java或其他一些易于理解的语言.

Answer 1

长话短说

诊断非常困难，不要自己动手，不要认为单个 DNS 查询或 whois 输出可以真正完全回答问题，它更复杂。

如果您信任他们，以下工具很有用，可以让生活变得更简单：

• https://dnssec-debugger.verisignlabs.com/正如很久以前在另一个答案中报道的那样
• https://dnsviz.net/基于特定查询的 DNS 层次结构的非常好的显示，其中
• https://zonemaster.net/通用区域检查器

至少最后两个也是可以在本地下载并安装以进行相同测试的软件；您还可以使用digDNSSEC 或其后继者delv（见下文），并unbound提供drill等效功能集的实用程序。

“我需要弄清楚域野兔是否在 NIC 上标记为使用 DNSSEC。”

根据您的问题的以下内容，这不是相关内容或措辞不当。

whois 输出中写入的内容没有用：它确实可以显示有时DNSSEC: Yes或某些等效内容，但 Whois 和 DNS 是两个独立的东西，如果您想解决 DNS 问题，您应该留在 DNS 领域，所以让我们忽略暂时使用 whois。

回到dig +dnssec <domain> dnskey，这是一个好的方向，但会带来两个大问题：

1. 您使用时dig没有指定@查询的名称服务器。因此，您将得到的答复将来自您可能控制或可能不控制的某个递归名称服务器，它可能会或可能不会对您撒谎，并且其通往您的路径可能会或可能不会控制，在后一种情况下，可以修改答案过境；要解决这一点，您实际上需要查询该域的权威名称服务器之一，因此您首先需要找到它们；这可能会变得复杂，因为您需要使用 DNSSEC 来确保您在所有查询中获得有效答复，同时 DNSSEC 中的任何错误都会给您SERVFAIL答复
2. 第二个大问题是，基本上你的查询将显示是否某些 DNSKEY 与区域数据一起发布，以及任何签名，但：
   1. 它不能确保您要求的递归解析器已验证任何内容（因此签名可能都是伪造的），因为要做到这一点，您需要而不是+nocdflag（+dnssec触发签名显示，又称RRSIG记录）；+cdflag实际上是一个禁用验证的标志，因此您需要反转它（因为解析器可能会默认验证，在这种情况下，与dig结果进行比较dig +cd可以帮助解释观察到的错误是否与 DNSSEC 相关（所有 DNSSEC 失败都是目前只是返回SERVFAIL一个通用错误代码，可能会发生在与 DNSSEC 无关的无数其他情况下；正在开展工作，向 DNS 交换添加更丰富的错误报告）
   2. 最后，即使一切顺利，最终域已发布的事实DNSKEY并不意味着它启用了 DNSSEC，因为要使其正常工作，它必须有一条与DS该特定密钥匹配但发布在父级权威名称服务器上的记录，即注册表的那些；如果没有这样的记录（及其带有密钥本身发布的签名，并且其本身对应于DS更高一级的其他记录，依此类推递归到 DNS 根），即使 aDNSKEY被发布，它也永远不会被信任，因此该域不确实有 DNSSEC。

像解析器一样进行验证

因此，事实上，要从头开始并正确执行所有操作，您需要做的就是执行递归验证名称服务器将执行的操作：它将 DNSSEC 验证您的域（或失败）。这是证明该域启用了 DNSSEC 的唯一测试，因为这意味着它已发布了所需的内容，父级也在发布其所需的内容，等等。

当然，手动重做所有这些并不是一个好主意，因为 DNSSEC 验证很复杂。

相反，您要做的是，安装一个本地验证解析器（例如）unbound或使用类似的库getdns（它将为您处理所有这些事情），或者使用远程递归名称服务器来为您验证 DNSSEC（当且仅当您完全信任这两者时）有问题的名称服务器以及您和它之间的所有网络路径（或者您现在使用 DoH 或 DoT 将 DNS 交换包装到 TLS 流中）。因为如果您使用不信任的远程服务器，它可能会在 DNSSEC 验证结果方面对您撒谎，并且如果您信任名称服务器而不是网络路径，那么主动攻击者可以在结果从递归名称服务器到达您之前对其进行修改。

请注意，bind 的最新版本提供了delv专门用于digDNSSEC 相关故障排除的后继版本：https://kb.isc.org/docs/aa-01152

BIND 9.10 包含一个新的调试工具，它是 dig 的继任者。所以，当然，我们必须将其命名为 delv。它的工作方式与 dig 非常相似，但它更好地理解 DNSSEC。

delv +vtrace清楚地显示每个步骤的所有验证和DS/DNSKEY记录检索。

DNSSEC 显示在 whois 中

最后回到这一点，讨论它的真正含义。

如果注册机构在某些 whois 输出中显示一点，表明该域已“签名”、DNSSEC 处于活动状态，则这仅意味着一件非常狭隘的事情：在过去的某个时刻（可能是很久以前），注册商代表其客户赞助该域名，发送加密材料（相当于 aDNSKEY或DS记录，具体取决于注册管理机构政策；如果是这样，则DS注册商希望注册管理机构将其按原样发布在注册管理机构权威名称服务器中；如果是这样相反DNSKEY，注册管理机构将自行计算DS要发布的值；有时注册服务机构必须将两者都发送，以便注册管理机构可以仔细检查DS从DNSKEY) 到注册管理机构的计算结果是否正确（通常是通过 EPP），稍后（几分钟后）小时/天）DS记录出现在注册机构权威域名服务器中。

但：

1. 如今很少有注册管理机构会在更新时进行检查，因此当子区域DS绝对没有发布任何记录时，注册商可以发送添加记录的请求。DNSKEY这将导致DNSSEC: yeswhois 输出，但该域对于任何解析名称服务器都将失败
2. 即使在此更新发生时一切设置正确，名称服务器也可能已更改（更改已签名域的名称服务器是一个难题，特别是如果旧提供商不合作并且没有良好的通用万无一失的解决方案，除了停止对域进行签名一段时间，然后在名称服务器更改后退出）
3. 即使不更改名称服务器本身，区域的内容也可能会被错误或自愿更改，因此DNSKEY在DS仍发布时删除，其效果与第一点相同。这种情况发生的频率远远超出预期/希望。

请注意，某些注册管理机构会对它们发布的所有域进行异步 DNSSEC 检查，并在域设置不再正确时向注册商和/或最终客户端发出警告。