我正试图找一种方法来查看某个域是否正在使用DNSSEC。从这个帖子：How can I check if a domain uses DNSSEC?我学会了
dig +dnssec <domain> dnskey
可以揭示很多东西。但经过一些实验，我意识到它只显示名称服务器是否设置了DNSSEC。我需要弄清楚的是，域名是否标记为在NIC使用DNSSEC。
我尝试用dnssec implementations查看python，但他们似乎都在查看名称服务器而不是原来的NICzone。
在挖掘之后，我注意到一些NICS（例如sidnl.nl）在WHOIS数据中记录了它，但由于这几乎不可靠（并非所有NICS都这样做），我正在寻找更好的方法。
ansers不一定是编程/使用代码片段，但如果它们是我会很高兴，如果它是python / C＃/ java或其他语言易于理解的语言。
答案 0 :(得分：2)
使用verisign的{dnssec调试器：http://dnssec-debugger.verisignlabs.com/。
答案 1 :(得分：2)
很难诊断，不要自己做，不要以为单个DNS查询或whois输出可以真正完全回答问题，这更加复杂。
如果您信任它们，那么以下工具将很有用，并使生活更简单：
至少最后两个也是您可以在本地下载并安装以进行相同测试的软件；您还拥有dig或DNSSEC的后继者delv（请参见下文），并且unbound为等效功能集提供了drill实用程序。
这与您的问题无关，或者措辞不当。
whois输出中写的内容没有用：确实可以有时显示DNSSEC: Yes或其他等效内容，但是Whois和DNS是两个不同的东西，如果您要处理DNS问题，则应留在DNS土地，所以让我们现在暂时忽略whois。
回到dig +dnssec <domain> dnskey，这是一个很好的方向，但首先要解决两个大问题：
dig，而没有用@指定查询的名称服务器。因此，您将得到的回复将来自某个递归名称服务器，该名称服务器可能会或可能不会控制您，可能会或可能不会欺骗您，并且到达您的路径可能会或可能不会控制，在后一种情况下，可以修改答案过境要解决此问题，实际上您需要查询域的权威名称服务器之一，因此您首先需要找到它们；这可能会变得很复杂，因为您需要使用DNSSEC来确保您在所有查询中均得到有效的答复，同时DNSSEC中的任何错误都会给您SERVFAIL作为答复+nocdflag而不是+dnssec（触发显示签名，又称RRSIG记录）； +cdflag实际上是一个禁用验证的标志，因此您需要将其反转（因为解析程序可能默认情况下进行验证，在这种情况下，将dig与dig +cd的结果进行比较可以帮助解释如果观察到的错误是否与DNSSEC相关（所有DNSSEC故障当前仅返回SERVFAIL，这是通用错误代码，在与DNSSEC不相关的许多其他情况下可能会发生这种错误； there are works ongoing to add richer error reports to DNS exchanges）< / li>
DNSKEY的事实也并不意味着它已启用DNSSEC，因为要使其正常工作，它必须具有{{1} }记录与该特定键匹配但在父权威名称服务器（即注册表的那些名称服务器）上发布的记录；没有这样的记录（并且它的签名本身已经发布，并且本身与其他DS相对应，则记录的级别更高，依此类推，直到DNS根目录为止），即使发布了DS也是如此将永远不会被信任，因此该域实际上没有DNSSEC。因此，要实际上从头开始一切并正确地做，您需要做的是做一个递归验证名称服务器将要做的事情：它将使DNSSEC验证您的域（或失败）。这是唯一证明该域已启用DNSSEC的测试，因为这意味着该域已经发布了所需的内容，父级也在发布了所需的内容，等等。
当然，由于DNSSEC验证很复杂，因此手动重做所有这些都是一个坏主意。
您要做的是安装本地验证解析器（如DNSKEY或使用库（如unbound）来为您解决所有这些问题，或者您使用远程递归名称服务器并且仅当您完全信任有问题的名称服务器及其之间的所有网络路径时，才可以为您验证DNSSEC（或者现在使用DoH或DoT将DNS交换包装到TLS流中） ）。
因为如果您使用不信任的远程服务器，它可能会欺骗您有关DNSSEC验证结果的信息，并且如果您信任命名程序但不信任网络路径，则活动的攻击者可以修改结果，然后再从递归名称服务器中获取结果
请注意，最新版本的绑定提供了getdns，它是delv的后继版本，专门用于与DNSSEC相关的疑难解答：https://kb.isc.org/docs/aa-01152
BIND 9.10包含一个新的调试工具，可以作为后续的挖掘工具。因此，当然，我们必须将其命名为delv。它的工作原理与dig非常相似，但对DNSSEC的理解更好。
dig清楚地显示了所有验证，并且在每个步骤都检索了delv +vtrace / DS记录。
最后回到这一点，讨论其真正含义。
如果注册表在某些whois中显示一个点，则表明该域已“签名”，表明DNSSEC是活动的，这仅意味着一件非常狭窄的事情：在过去的某个时候（可能很久以前） ，代表该域名赞助此域名的注册服务商会发送加密材料（根据注册管理机构的政策，等同于DNSKEY或DNSKEY记录；如果是DS注册服务商希望注册管理机构像在注册机构权威名称服务器中一样发布它；如果这是DS，则注册管理机构将自己计算要发布的DNSKEY值；有时注册服务商必须同时发送这两个值注册表可以仔细检查DS是从DS到注册表的正确计算，通常是通过EPP，并且稍后（几小时/天），DNSKEY记录出现了在注册表权威名称服务器中。
但是：
DS时，注册服务商可以发送添加DS记录的请求。这将导致DNSKEY的whois输出，但该域将无法解析任何名称服务器DNSSEC: yes仍被发布时将DNSKEY删除，效果与第一个相同。点。这种情况的发生频率远比预期/希望的要高。请注意，某些注册机构会对其发布的所有域进行异步DNSSEC检查，并警告注册机构和/或最终客户（如果其域设置不正确）。