6

我正在尝试找到一种方法来查看域是否正在使用 DNSSEC。来自此线程：如何检查域是否使用 DNSSEC？我了解到

dig +dnssec <domain> dnskey

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

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

在四处挖掘之后，我注意到一些 NICS（例如 sidnl.nl）在 WHOIS 数据中对其进行了注释，但由于这几乎不可靠（并非所有 NICS 都这样做）我正在寻找更好的方法。

分析器不必是编程/使用代码片段，但如果是，我会很高兴它是 python/C#/java 或其他具有易于理解语法的语言。

4

2 回答 2

4

TL;博士

诊断非常困难，不要自己做，不要以为单一的DNS查询或者whois输出就可以真正完全回答问题，比较复杂。

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

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

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

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

whois 输出中写的东西没有用：它确实有时可以显示DNSSEC: Yes或某些等价物，但是 Whois 和 DNS 是两个独立的东西，如果你想处理 DNS 问题，你应该留在 DNS 领域，所以让我们忽略谁是现在。

回到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. 最后，即使所有内容都在此处单击，最终域已发布 a 的DNSKEY事实并不意味着它已启用 DNSSEC，因为要使其正常工作，它必须具有DS与该特定密钥匹配但发布在父权威名称服务器上的记录，即登记处的那些；如果没有这样的记录（并且它的签名本身带有一个已发布的密钥，并且它本身对应于DS更高一级的其他记录，依此类推，直到 DNS 根），即使 aDNSKEY已发布，它也永远不会被信任，因此域不真的有DNSSEC。

像解析器一样进行验证

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

当然，在您这边手动重做所有这些是一个坏主意，因为 DNSSEC 验证很复杂。

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

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

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

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

在 whois 中显示的 DNSSEC

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

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

但：

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

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

于 2019-03-29T00:40:20.897 回答
2

使用来自 verisign 的 dnssec 调试器：http: //dnssec-debugger.verisignlabs.com/。

于 2013-01-02T23:33:45.843 回答