TL;DR
诊断难度很大，不要自己做，不要以为单一的DNS查询或者whois输出就可以真正完全回答问题，比较复杂。
如果您信任他们，以下工具很有用，可以让生活变得更简单：
至少最后两个也是您可以在本地下载并安装以进行相同测试的软件；您还拥有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 验证结果方面对您撒谎，并且如果您信任名称服务器而不信任网络路径，那么主动攻击者可以在结果从递归名称服务器到达您之前对其进行修改.
请注意，最新版本的 bind 提供了 delv，它是 dig 的继承者，专门用于与 DNSSEC 相关的故障排除：https://kb.isc.org/docs/aa-01152
BIND 9.10 包含一个新的调试工具，它是 dig 的继任者。所以，当然，我们不得不将它命名为 delv。它的工作方式与 dig 非常相似，但它更了解 DNSSEC。
delv +vtrace 清楚地显示所有验证和每个步骤中的DS/DNSKEY 记录检索。
在 whois 中显示的 DNSSEC
最后回到这一点，讨论它的真正含义。
如果注册管理机构在某些 whois 输出中显示一个点，表明该域已“签名”，表明 DNSSEC 处于活动状态，这仅意味着一件非常狭窄的事情：在过去的某个时间点（可能是很久以前） ，赞助此域名的注册商代表其客户发送加密材料（相当于DNSKEY 或DS 记录，取决于注册策略；如果是DS，注册商希望注册在注册表权威名称服务器中按原样发布它；如果这是 DNSKEY，则注册表将自行计算要发布的 DS 值；有时注册商必须同时发送两者，以便注册表可以仔细检查 @987654358 @ 是从 DNSKEY) 正确计算到注册表的，通常是通过 EPP，不久之后（几小时/几天）DS 记录出现在注册表权威名称服务器中。
但是：
- 现在很少有注册管理机构会在更新时进行检查，因此当子区域绝对没有发布
DNSKEY 时，注册服务商可以发送请求以添加 DS 记录。这将导致在 whois 输出中出现 DNSSEC: yes，但该域对于任何解析名称服务器都会失败
- 即使在此更新发生时一切设置正确，名称服务器也可能已更改（更改已签名域的名称服务器是一个难题，特别是如果旧提供商不合作，并且没有任何好处通用的万无一失的解决方案，除了停止签署域名一段时间，然后在域名服务器更改后将其辞职）
- 即使不更改名称服务器本身，区域的内容也可能会因错误或自愿而更改，因此在仍发布
DS 时删除DNSKEY，其效果与第一点相同。这种情况发生的频率远远超出预期。
请注意，有些注册管理机构会对他们发布的所有域进行异步 DNSSEC 检查，如果他们的域不再正确设置，则会警告注册商和/或最终客户。