python - 我如何查看域是否使用DNSSEC

Question

我正在尝试寻找一种方法来查看域是否正在使用DNSSEC。从这个线程:How can I check if a domain uses DNSSEC?我了解到

dig +dnssec <domain> dnskey

可以揭示很多事情。但是经过一些试验，我意识到它仅显示是否使用DNSSEC设置了名称服务器。我需要弄清楚的是，如果在NIC上将域标记为使用DNSSEC了。

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

深入研究后，我注意到某些NICS(例如sidnl.nl)在WHOIS数据中对此做了注释，但是由于这几乎不可靠(并非所有NICS都这样做)，因此我正在寻找一种更好的方法。

答案不必一定是编程/使用代码段，但是如果答案是肯定的，那么如果它是python/C#/java或其他具有易于理解的语法的语言，我将很高兴。

Answer 1

TL; DR

诊断非常困难，不要自己做，不要以为单个DNS查询或whois输出确实可以完全回答问题，这更加复杂。

如果您信任它们，那么以下工具将很有用，并使生活更简单:

https://dnssec-debugger.verisignlabs.com/很久以前在另一个答案中报告

https://dnsviz.net/使用

非常漂亮地显示基于特定查询的DNS层次结构

https://zonemaster.net/通用区域检查器

至少最后两个也是您可以在本地下载并安装以进行相同测试的软件。您还拥有 dig，或者它的DNSSEC的后继者 delv(请参见下文)，并且 unbound为等效功能集提供 drill实用程序。

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

这与您的问题无关，或者措辞不当。

whois输出中写的内容没有用:确实可以有时显示 DNSSEC: Yes或某些等效内容，但是Whois和DNS是两个不同的东西，如果您要处理DNS问题，则应该留在DNS领域，所以让我们来现在暂时忽略Whois。

回到 dig +dnssec <domain> dnskey，这是一个很好的方向，但是从两个大问题开始:

您正在使用dig而不用@指定查询的名称服务器。因此，您将得到的答复将来自某个递归名称服务器，该名称服务器可能会或可能不会控制您，可能会或可能不会欺骗您，并且到达您的路径可能会或可能不会控制，在后一种情况下，可以修改答案过境要解决此问题，实际上您需要查询域的权威名称服务器之一，因此您首先需要找到它们；这可能会变得很复杂，因为您需要使用DNSSEC来确保您在所有查询中都得到有效的答复，同时DNSSEC中的任何错误都将使SERVFAIL作为答复

第二个大问题是，基本上，您的查询将显示是否发布了与区域数据一起发布的某些DNSKEY，以及以下任何签名:

不能确保您要求的递归解析器已经验证了任何内容(因此签名可能都是伪造的)，因为这样做您需要+nocdflag而不是+dnssec(这会触发签名的显示，也就是RRSIG记录)； +cdflag实际上是一个禁用验证的标志，因此您需要将其反转(因为解析程序可能默认情况下进行验证，在这种情况下，将dig与dig +cd结果进行比较可以帮助解释观察到的错误是否与DNSSEC相关(所有DNSSEC故障目前仅返回SERVFAIL，这是一个通用错误代码，在与DNSSEC不相关的其他多种情况下，可能会发生这种错误； there are works ongoing to add richer error reports to DNS exchanges)

，最后，即使所有内容都单击此处，最终域已发布DNSKEY的事实也并不意味着它已启用DNSSEC，因为要使其正常工作，它必须具有与该特定键匹配的DS记录，但必须发布在父级权威名称服务器，即注册中心的名称服务器；如果没有这样的记录(其签名本身已发布，并且其签名本身与某个其他DS相对应，则记录的级别更高，依此类推，直到DNS根目录为止)，即使DNSKEY发布，它也永远不会被信任，因此该域确实没有DNSSEC。

像解析器一样进行验证

因此，实际上要从头开始一切并正确地做，您需要做的是做递归验证名称服务器将要做的事情:它将使DNSSEC验证您的域(或失败)。这是唯一证明该域已启用DNSSEC的测试，因为这意味着该域已发布了所需的内容，父级也已发布了所需的内容，依此类推。

当然，由于DNSSEC验证很复杂，因此手动重做所有这些都是一个坏主意。

相反，您要做的是安装本地验证解析器(如 unbound)或使用像 getdns这样的库来为您解决所有这些问题，或者您使用远程递归名称服务器，当且仅当时才为您验证DNSSEC 您完全信任所讨论的名称服务器以及您与它之间的所有网络路径(或者现在使用DoH或DoT将DNS交换包装到TLS流中)。
因为如果您使用不信任的远程服务器，它可能会欺骗您有关DNSSEC验证结果的信息，并且如果您信任命名程序但不信任网络路径，则 Activity 的攻击者可以修改结果，然后再从递归名称服务器中获取结果。

请注意，bind的最新版本提供了delv，它是dig的后继产品，专门用于与DNSSEC相关的疑难解答:https://kb.isc.org/docs/aa-01152

BIND 9.10 contains a new debugging tool that is a successor to dig. So, of course, we had to name it delv. It works very much like dig, but it understands DNSSEC better.

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

DNSSEC显示在whois中

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

如果注册管理机构在某些Whois输出中显示一个点，则表明该域已“签名”，表明DNSSEC处于 Activity 状态，这仅意味着一件非常狭窄的事情:在过去的某个时候(可能很久以前)，注册商代表其客户赞助此域名，发送了加密 Material (等效于DNSKEY或DS记录，具体取决于注册管理机构的政策；如果是DS，则注册服务商希望注册管理机构像在注册管理机构权威名称服务器中一样发布该加密 Material ;如果这是一个DNSKEY，则注册表会自行计算要发布的DS值；有时注册服务商必须同时发送这两个值，以便注册表可以再次检查DS是否从DNSKEY正确计算到注册表，通常是通过EPP ，然后过了一会儿(几个小时/天)，DS记录出现在注册表权威名称服务器中。

但:

如今，很少有注册机构在更新时进行检查，因此当子区域绝对没有发布DS时，注册服务商可以发送添加DNSKEY记录的请求。这将在whois输出中导致DNSSEC: yes，但是对于任何解析的名称服务器

，域都将失败

即使在此更新发生时一切设置正确，名称服务器也可能已更改(更改已签名域的名称服务器是一个难题，尤其是如果旧提供程序不合作且没有良好的通用万无一失的情况下)解决方案，除了停止对域进行一段时间的签名，然后在名称服务器更改后将其注销)

即使不更改名称服务器本身，也可以通过错误或自愿更改区域的内容，因此在DNSKEY仍被发布时将DS删除，其效果与第一点相同。发生这种情况的频率远远超过预期/期望的频率。

请注意，某些注册机构会对它们发布的所有域进行异步DNSSEC检查，并警告注册机构和/或最终客户端(如果其域设置不正确)。