了解如何排查 DNSSEC 相关问题。
Dig 是用于向名称服务器查询 DNS 记录的命令行工具。
例如，dig 可以向 DNS 解析器询问 www.cloudflare.com 的 IP 地址：
dig www.cloudflare.com +short198.41.215.162
198.41.214.162选项 +short 仅输出结果。
使用 +dnssec 验证 DNS 记录是否已签名：
dig www.cloudflare.com +dnssec +short198.41.214.162
198.41.215.162
A 13 3 300 20180927180434 20180925160434 35273 cloudflare.com. DYYZ/bhHSAIlpvu/HEUsxlzkC9NsswbCQ7dcfcuiNBrbhYV7k3AI8t46 QMnOlfhwT6jqsfN7ePV6Fwpym3B0pg==在此示例中，输出的最后一行是 RRSIG 记录。RRSIG 是附加到记录上的 DNSSEC 签名。借助 RRSIG，DNS 解析器可以判断 DNS 响应是否可信。
Dig 还可以检索用于验证 DNS 记录的公钥 DNSKEY：
dig DNSKEY cloudflare.com +short257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+ KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
256 3 13 koPbw9wmYZ7ggcjnQ6ayHyhHaDNMYELKTqT+qRGrZpWSccr/lBcrm10Z 1PuQHB3Azhii+sb0PYFkH1ruxLhe5g==域名的 DNS 记录均使用相同的公钥签名。因此，应查询 apex 域名（cloudflare.com）的公钥，而不是子域（www.cloudflare.com）的公钥。
DNS 响应包含两条记录：
DNSKEY记录 256 是称为区域签名密钥（ZSK）的公钥。ZSK 用于验证A、MX、CNAME、SRV等 DNS 记录签名。DNSKEY记录 257 称为密钥签名密钥（KSK）。KSK 用于验证DNSKEY、CDS与CDNSKEY记录的签名。
在不使用 dig 的 +short 选项时，若响应头中出现 ad 标志，则表示 DNS 响应已通过 DNSSEC 认证：
dig www.cloudflare.com[...]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65326
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]
;; QUESTION SECTION:
;www.cloudflare.com. IN A
[...]
;; ANSWER SECTION:
www.cloudflare.com. 15 IN A 198.41.215.162
www.cloudflare.com. 15 IN A 198.41.214.162要可视化并发现潜在的 DNSSEC 问题：
- 前往 https://dnsviz.net/ ↗。
- 在出现的文本字段中输入域名。
- 若 DNSViz 此前从未分析过该站点，请选择 Analyze（分析）。
- 若该站点此前已被 DNSViz 分析过，请选择 Update Now（立即更新）。
以下示例展示了当权威名称服务器未提供与 TLD 名称服务器发布的 DS 记录匹配的有效 DNSKEY 记录时，dnsviz.net 如何显示不正确的委派：
完整验证域名签名（例如 cloudflare.com）需要验证顶级域（例如 .com）处的密钥签名密钥。
然后通过在根服务器级别检查 .com 的密钥签名密钥进行类似验证。DNSSEC 根密钥会分发给 DNS 客户端以完成信任链。
启用 DNSSEC 时，注册商的 DNS 处需要有一条 DS 记录。DS 记录包含公钥签名密钥的哈希以及有关该密钥的元数据。
使用 dig 查找 DS 记录：
dig +short DS cloudflare.com2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9使用 +trace 选项时，dig 可确认答案是由 cloudflare.com 的名称服务器还是 .com 的名称服务器返回。在此示例中，cloudflare.com 的 DS 记录由 e.gtld-servers.net 返回：
dig DS cloudflare.com +trace[...]
cloudflare.com. 86400 IN DS 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9
[...]
com. 172800 IN NS e.gtld-servers.net.
[...]
;; Received 1213 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 37 ms手动执行上述步骤的更简便替代方案是使用第三方工具 DNSViz。
若在更改权威 DNS 提供商时未更新或移除注册商处的旧 DNSSEC 记录，则会出现问题：
dig A brokendnssec.net @1.0.0.1;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10663通过使用带 +cd 选项的 dig 运行查询，确认 SERVFAIL 响应是否与 DNSSEC 相关。+cd 选项在不进行任何 DNSSEC 验证的情况下提供 DNS 结果。
dig A brokendnssec.net @1.0.0.1 +dnssec +cd +short104.20.49.61
104.20.48.61在此示例中，若使用 +cd 选项时收到正确的 DNS 响应，但使用 DNSSEC 的查询返回 SERVFAIL 响应，则说明 DNSSEC 配置错误。此问题通常发生在更改了权威名称服务器但未更新 DS 记录时。若攻击者尝试伪造查询响应，也可能出现此问题。
禁用 DNSSEC 后，DNSKEY 记录仍会出现在 DNS 查询与 zone 传输中。在 disabled 状态下，Cloudflare 仍会签名 zone 并提供 RRSIG、NSEC 与 DNSKEY 记录。这是预期行为，并非错误配置或故障。详情请参阅 DNSSEC 状态 与 RFC 8078 ↗。
不过，部分安全厂商或审计工具可能会将这些 DNSKEY 记录标记为有问题，报告“找到 DNSKEY 记录但未找到 DS 记录”，并将安全结果标为“可证明不安全（Provably Insecure）”。你可以使用 API 移除这些 DNSKEY 记录。
使用 Delete DNSSEC API 将 zone 转换为 deleted 状态。这会停止所有 zone 签名，并移除所有 DNSSEC 记录类型（RRSIG、NSEC、DNSKEY、CDS 与 CDNSKEY）：
Required API token permissions
At least one of the following token permissions is required:DNS Write
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dnssec" \
--request DELETE \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"有关 DNSSEC 状态的更多信息，请参阅 DNSSEC 状态。
移除 DNSKEY 记录后，验证它们不再出现在 DNS 响应中。空响应可确认移除成功。
dig DNSKEY example.com +short若 DNSKEY 记录仍然出现，请等待生存时间（TTL）过期。DNSKEY 记录通常具有较长的 TTL 值（通常为 3600 秒或更长），因此传播可能需要一小时或更长时间。
若发现 DNSSEC 实现存在问题，请联系域名的注册商，并确认 DS 记录与权威 DNS 提供商指定的内容匹配。若 Cloudflare 是权威 DNS 提供商，请按照使用 Cloudflare 配置 DNSSEC 的说明操作。