DNSSec 数据包中有三个标志，它们负责传达域的验证要求。

DO位

DO 位由解析器设置以指示它需要将身份验证资源记录包含在响应中。

如果解析器具有安全意识，它必须设置 DO 位。如果名称服务器收到没有 DO 位的消息，它必须删除任何身份验证资源记录。除非有特定的身份验证记录请求。

CD 位

该位允许中间名称服务器禁用签名验证。这基本上是说'不要费心验证事情，我会自己做，只需将原始记录发送给我'

AD位

这是实际回答您问题的部分。

当且仅当解析器端认为 Answer 部分中的所有 RRsets 和授权部分中任何相关的否定响应 RRs 是真实的时，名称服务器端应该设置 AD 位。

AD 位说，这些记录是真实的，它们是签名的。

执行安全查询

如果www.example.com配置了正确的键和资源记录。它仍然必须响应不了解 DNSSec 的客户端。DNSSec 被设计为向后兼容，它必须响应不理解 DNSSec 的请求。这确实会产生您强调的漏洞。

但是该过程存在，使用上述标志来确保只接收到真实的记录，但这需要解析器被配置为这样做。Bind 确实在DNSSec-validation标志中提供了这种机制（默认启用）

在命名中启用 DNSSec 验证。注意 DNSSec-enable 也需要设置为 yes 才能生效。默认值为是。

因此，如果您创建自己的 DNS 解析器，并将其配置为仅接受经过验证的响应，您将无法解析没有完整信任链与之关联的域。尽管没有 DNSSec 记录的域将像以前一样工作。

Google 的名称服务器之所以如此行事，是因为他们已将它们配置为在域受欢迎时忽略 AD 位。因此，如果 stackexchange 的证书有问题，Google 仍然会使用他们的名称服务器来解决。这似乎是一个决定，以防止 stackexchange 为大部分使用 Google DNS 的人放弃互联网。

编辑以回答实际问题！

如果您已经配置了安全解析器，并且上游的某个人可以劫持其查询，他们可以去除 DO 位，这将迫使上游服务器去除所有身份验证记录。当您的安全解析器收到该记录时，它只会假定您正在查找的域没有配置任何身份验证。

要执行此攻击，您甚至不需要完全插入中间，调整传出 DNS 数据包的能力就足够了。

这被认为是 DNSSec 最初设计的一部分。根据RFC3833 - 域名系统的威胁分析

虽然可以使用诸如 TSIG 或 IPsec 之类的通道安全机制对 DNS 消息进行签名，甚至可以使用 IPsec 对其进行加密，但这对于拦截攻击来说并不是一个很好的解决方案
[...]
对于频繁使用的名称服务器（例如根区域的服务器），这个成本几乎肯定会高得令人望而却步。然而，更重要的是，这种设计中的底层信任模型是错误的，因为它最多只能提供对 DNS 消息的逐跳完整性检查，而不会提供任何类型的端到端完整性检查

DNSSec 旨在防止一些特定的攻击，例如缓存中毒，中间人攻击由于上述原因而被简单地打了折扣。

简短的回答是：当您在区域中使用 DNSSEC 时，应签署所有记录。因此，不需要一种机制来明确传达此声明，因为它是 DNSSEC 签名区域的默认且唯一的策略。

没有例外。有一个NSEC3选择退出机制，但这更针对仅授权区域，如 TLD，以便通过仅签署本身启用 DNSSEC 的子区域来减小大小。

因此，如果该区域启用了 DNSSEC 并且解析器正在验证，它应该将所有未签名的记录视为验证失败并返回SERVFAIL.

有关详细信息，请参阅RFC4035 中的“4.3. 确定数据的安全状态”，并注意第 5 节中的最后一段：

解析器应该期望来自签名区域的身份验证信息。如果解析器已经配置了区域的公钥信息，或者如果区域的父级已签名并且来自父级的委托包含 DS RRset，则解析器应该相信该区域已签名。

总之，区域中密钥的存在以及区域中从根到该密钥的所有信任链的验证应该具有结果，区域中的所有记录都有随附的RRSIG记录来验证它们的真实性。

在这种情况下，获得没有RRSIG记录的回复也可能表明正在进行的攻击，因此这应该被视为验证错误，因此SERVFAIL.

现在，正如您自己引用的那样，各种解析器选择覆盖默认的标准行为并让一些无效或丢失的 DNSSEC 记录通过。这是一个本地政策决定，取决于每个解析器，但它显然超出了标准。

正如您所链接的那样，Google 会针对“非常受欢迎的域”之类的情况执行此操作，许多 ISP 会不时执行此操作，例如 Comcast，因为当域名配置不正确时，他们会受到指责（请参阅此示例：https:// www.darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked/d/d-id/1136990，您可以在https://ianix.com/找到相关问题的精选列表pub/dnssec-outages.html）。现在甚至有一个专门针对这个问题的 RFC：RFC7646: Definition and Use of DNSSEC Negative Trust Anchors

本文档定义了负信任锚 (NTA)，可用于通过在指定域禁用 DNSSEC 验证来缓解 DNSSEC 验证失败。

和：

如果由于顶级域 (TLD) 或流行域名（例如排名前 100 的网站）配置错误而导致验证失败，大量用户可能无法访问受影响的 TLD 或域中的内容或服务. 在这种情况下，一旦确认错误配置，就可以使用 NTA。“前 N 个”网站列表的一个示例是 Alexa“Web 上的前 500 个站点”[Alexa] 或解析器缓存中访问次数最多的名称列表。

您可能也对此草案感兴趣：https ://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-05处理验证解析器需要考虑的困难，两者都应考虑错误配置和敌对环境。