首页 / 内容指南 / 当前文章

DNSSEC 的 Secure、Insecure、Bogus、Indeterminate、AD、CD、DO、SERVFAIL 和 EDE 有什么区别？

发布于 2026-08-26 · Content Fleet 编辑部

DNSSEC 的 Secure、Insecure、Bogus、Indeterminate、AD、CD、DO、SERVFAIL 和 EDE 有什么区别？

快速对照

DNSSEC 验证从信任锚开始

验证器不是看到一个 RRSIG 就相信它，而是从本地配置的信任锚开始，沿父区 DS、子区 DNSKEY 和具体 RRset 的 RRSIG 建立认证链。每一步都要验证算法、密钥标签、摘要、签名时间、规范化数据和否定回答证明。

根区信任锚常是公共 DNS 验证的起点，但企业内部视图也可能使用本地信任锚或 Negative Trust Anchor。不同验证器的信任锚、时钟、算法支持和缓存状态不同，同一时刻可能得到不同结果。排障报告必须注明查询的是哪台解析器，不能只写“DNSSEC 失败”。

DNSSEC 证明 DNS 数据来源认证与完整性，不对网页内容真实性、服务器漏洞或域名所有者信誉作保证。Secure 的恶意域名仍然可能提供恶意内容。

Secure：认证链能够验证

RFC 4033 将 Secure 描述为验证器能够构建从信任锚到数据的认证链，并验证相关签名的数据。正向回答的 A、AAAA、MX 等 RRset 可以是 Secure；经过正确签名的 NXDOMAIN 或 NODATA 否定回答也可以是 Secure，因为 NSEC 或 NSEC3 能证明名称或类型不存在。

Secure 不要求应用一定看见所有 DNSSEC 记录。递归解析器可以在上游取得并验证 RRSIG，然后向普通 stub 返回业务记录和 AD 位。是否携带 RRSIG 还受 DO 位、缓存和响应大小影响。

验证成功依赖当前时间落在 RRSIG 的 inception 与 expiration 之间。权威区签名续期失败、验证器时钟严重偏差或算法不受支持，都可能让原本正确的链无法保持 Secure。

Insecure：被认证地证明没有保护

Insecure 不是“验证失败”。典型情况是父区没有为子区发布 DS，验证器利用父区受保护的否定证明确认该委派没有 DNSSEC 信任链，因此继续把子区数据作为未认证数据使用。

这与父区发布了 DS、但子区 DNSKEY 不匹配完全不同。前者是正常未签名委派，状态可为 Insecure；后者表示认证链承诺存在却无法完成，通常成为 Bogus。

在 Insecure 分支下偶然看到 DNSKEY 或 RRSIG，也不会自动建立从现有信任锚出发的信任。验证的关键是可验证链，不是记录数量。管理员不能通过“先上传 RRSIG、以后再加 DS”假设互联网已经安全启用 DNSSEC。

Bogus：应能验证却失败

Bogus 表示验证器认为数据本应通过认证，但签名、密钥或否定证明等检查失败。常见原因包括父区 DS 与子区 DNSKEY 不匹配、RRSIG 过期或尚未生效、签名覆盖的 RRset 与权威数据不一致、NSEC/NSEC3 证明错误、算法处理问题和报文在路径中被损坏。

Bogus 是安全处理结果，不等同攻击结论。DNSSEC 密钥轮换顺序错误、隐藏主服务器未同步、CDN 或多权威节点发布版本不一致，都可能制造相同现象。验证器通常不会把 Bogus 数据作为正常答案交给未设置 CD 的客户端，而返回 SERVFAIL。

排障时先用多个权威节点直接查询，比较 SOA serial、DNSKEY、DS、RRSIG 时间与 Key Tag，再对照验证器日志。直接关闭验证只会恢复表面解析，同时失去完整性保护，不能算修复。

Indeterminate：信息不足以分类

Indeterminate 表示验证器不能把数据确定归入 Secure、Insecure 或 Bogus。可能原因包括没有适用的信任锚、缺少完成判断的信息，或数据处于验证器不能处理的范围。

它与 Insecure 的区别在于证据：Insecure 是验证过程得出了“没有认证链”的结论；Indeterminate 是未能得出完整结论。产品界面常把二者都显示成“未验证”，因此需要查看解析器的详细验证状态或日志，不能从普通 dig 输出反推出所有内部状态。

在只配置局部信任锚的企业环境中，锚覆盖范围之外的数据可能无法按公共递归器的方式分类。文档应明确每个验证域及其信任锚来源。

DO 位：请返回 DNSSEC 相关记录

DO（DNSSEC OK）位位于 EDNS OPT 伪记录的 flags 字段。RFC 3225 定义它用于查询方表示能够接收 DNSSEC 安全 RR。设置 +dnssec 的查询通常会带 DO 位，使递归器在响应中包含适用的 RRSIG 等数据。

DO 位不表示客户端已经验证，也不强迫递归服务器验证。一个非验证型解析器仍可转发 DNSSEC RR；验证型解析器即使面对未设置 DO 的 stub，也可能为自身缓存和安全策略在上游查询时设置 DO 并执行验证。

DO 还可能增大 UDP 响应，引发截断、TCP 回退或路径 MTU 问题。看到 +dnssec 查询失败而普通查询成功，应同时检查报文大小和传输路径，不能立即断定签名坏了。

CD 位：请求关闭检查拦截

CD（Checking Disabled）位在 DNS 头中由查询方设置。它告诉支持 DNSSEC 的递归解析器：即使数据无法通过验证，也请把可取得的数据返回，让客户端自己检查。RFC 4035 要求安全感知的递归服务器在 CD=0 时执行适当检查；CD=1 则改变其向客户端交付验证失败数据的行为。

CD 不是“不要查询 DNSSEC 记录”，也不是“整个链路禁用 DNSSEC”。一个本地验证器可用 CD=1 向上游取得原始数据，再自行验证。排障命令 dig +cd 能帮助区分“权威数据完全取不到”与“验证器因 Bogus 拦截”，但不能把 +cd 得到答案当作配置健康。

应用若不自行验证却长期设置 CD，会绕过递归器的重要保护。它应只用于明确的验证架构或诊断。

AD 位：解析器认为数据已认证

AD（Authenticated Data）位由响应服务器设置，表示响应的 Answer 与 Authority 部分中相关 RRset 被其认为是可信认证数据。客户端只有在信任该递归器，并且到递归器的通道未被篡改时，才能使用这个信号。

从公共 Wi-Fi 上通过明文 UDP 查询远端解析器，即使看见 AD，也不能自动获得端到端保证；中间人可以修改 DNS 头。可信本地网络、受保护的 DoT/DoH 通道或本机验证能改善这个信任边界。

没有 AD 也不能直接判定 Bogus。答案可能是 Insecure、解析器不做验证、策略不设置 AD、客户端设置了 CD，或响应处理方式不满足置位条件。必须结合 RCODE、DO/CD、数据和解析器能力判断。

SERVFAIL：通用失败，不是 DNSSEC 专用错误

SERVFAIL 是基础 DNS RCODE，早于 DNSSEC 存在。超时、权威服务器不可达、循环、内部资源耗尽、格式问题以及 DNSSEC Bogus 都可能导致它。仅凭 status: SERVFAIL 无法定位根因。

若普通验证查询 SERVFAIL，而同一解析器的 +cd 查询返回带签名数据，DNSSEC 验证失败的可能性明显上升，但仍应检查具体链条。若两种查询都超时或 SERVFAIL，则可能是传输、委派、权威可用性或解析器自身故障。

比较测试必须保持查询名、类型、解析器和时间一致。缓存会导致修复后的域名在不同解析器上短暂表现不同，负缓存与 SERVFAIL 缓存策略也会影响复测。

EDE：给 SERVFAIL 增加可诊断原因

RFC 8914 定义 Extended DNS Errors。服务器可在 EDNS OPT 中返回一个 Info-code 和可选的 Extra Text，例如 Unsupported DNSKEY Algorithm、DNSSEC Bogus、Signature Expired、Signature Not Yet Valid、DNSKEY Missing、RRSIGs Missing、No Reachable Authority 等。

EDE 是补充信息，不替代 DNS 头中的 RCODE。一个响应仍可能是 SERVFAIL，同时携带更具体的 EDE。客户端和中间设备不认识 EDE 时，基础 DNS 行为仍应成立。

Extra Text 面向诊断，不应被应用当作稳定机器接口，也不应包含敏感内部细节。自动化应优先按 Info-code 分类，并保留解析器、时间、查询和原始响应作为证据。

NXDOMAIN、NODATA 与验证状态是正交关系

NXDOMAIN 表示查询名称不存在；NODATA 通常表现为 NOERROR 但所问类型无记录。两者都可以通过 DNSSEC 否定证明成为 Secure，也可以位于未签名分支而为 Insecure，或因 NSEC/NSEC3 证明错误而成为 Bogus。

因此“NXDOMAIN 就没有签名”是错误的。RFC 8020 还说明，来自权威服务器的 NXDOMAIN 可用于推断其下级名称也不存在，但验证器仍需正确处理安全状态和区域边界。

判断否定回答时要检查 RCODE、SOA、NSEC/NSEC3、RRSIG 和认证链，而不只是 Answer 区是否为空。

一组可重复的诊断命令

dig @resolver.example name.example A +dnssec
dig @resolver.example name.example A +dnssec +cd
dig @auth.example name.example A +dnssec +norecurse
dig @resolver.example name.example DS +dnssec
dig @resolver.example name.example DNSKEY +dnssec

第一条观察验证型递归器的正常结果、AD、RCODE 与 EDE；第二条请求返回未被验证失败拦截的数据；第三条直接比较各权威节点；后两条检查父子链关键记录。真实服务器地址应明确写出，不要依赖系统默认解析器后又误称查询了公共 DNS。

命令输出还需记录时间，因为 RRSIG 生命周期与缓存会变化。检查本机 UTC 时钟、UDP/TCP 可达性，并在需要时抓取完整报文。

密钥轮换为何常制造 Bogus

KSK 或 CSK 轮换横跨父区 DS 与子区 DNSKEY，双方发布、缓存和撤除顺序必须留出 TTL。过早撤下旧 DNSKEY、父区仍保留旧 DS，或新 DS 生效前只用新密钥签名，都可能切断认证链。

ZSK 轮换主要影响 DNSKEY 集与业务 RRset 的签名衔接，也需确保验证器在缓存组合下始终能找到有效签名。多权威节点应发布同一阶段数据，隐藏主、辅助 DNS 与托管平台之间的同步必须逐节点验证。

回滚不能只把区文件改回去，还要考虑父区操作不可瞬时撤销和缓存存活。上线前应把 TTL 降低窗口、父区 SLA、双签或预发布步骤写入 runbook。

常见误区

响应有 RRSIG 就是 Secure

错误。RRSIG 只是验证材料，必须从信任锚沿 DS/DNSKEY 链验证，并检查签名与数据。

没有 AD 就是 Bogus

错误。Insecure、非验证型解析器、非可信响应路径或具体查询策略都可能没有 AD。

`dig +dnssec` 会在本机完成 DNSSEC 验证

错误。它主要设置 DO 位请求 DNSSEC RR；是否本地验证取决于所用工具和验证器。

`+cd` 能修复 DNSSEC

错误。它只请求解析器不要因检查失败而拦截数据，适合诊断，不能修复签名链。

SERVFAIL 一定是签名过期

错误。SERVFAIL 是通用失败；应查看 EDE、验证器日志、权威可达性和实际认证链。

FAQ

1. Secure 与“域名安全”是同一概念吗？

不是。Secure 只表示 DNS 数据在 DNSSEC 信任链下通过来源认证和完整性验证，不评价网站内容、TLS 或运营者信誉。

2. Insecure 是否表示正在被劫持？

不是。它通常表示验证器已证明该委派没有 DNSSEC 保护。数据缺少认证，但这本身不是攻击证据。

3. 父区有 DS、子区缺少对应 DNSKEY 会怎样？

认证链承诺存在却无法完成，通常会被判为 Bogus，验证型递归器对普通客户端常返回 SERVFAIL。

4. DO=1 为什么响应里仍可能没有 RRSIG？

名称可能位于 Insecure 分支、缓存或服务器行为不同、回答并无相应签名材料，或中间设备处理异常。DO 只是请求能力信号，不保证结果。

5. AD=1 可以完全信任吗？

只有在客户端信任置位的解析器，并信任到它的传输路径时才有意义。需要更强边界时使用本机验证或受保护传输。

6. 为什么 `+cd` 有答案，普通查询却 SERVFAIL？

这通常说明递归器能取得数据，但正常模式下验证失败并进行了拦截。应继续检查 DS、DNSKEY、RRSIG、时间与 EDE。

7. EDE 会取代 SERVFAIL 吗？

不会。EDE 作为 EDNS 选项补充基础 RCODE，兼容旧客户端；自动化应同时记录二者。

8. DNSSEC 修复后为什么部分用户仍失败？

递归器可能缓存旧 DS、DNSKEY、RRSIG、否定回答或失败状态。还应检查各权威节点是否同步，并等待相关 TTL 后复测。

参考来源