一次失败的 DNSSEC 密钥轮换让 .AL 顶级域名无法通过验证。为了恢复解析，1.1.1.1 临时部署了负信任锚（Negative Trust Anchor，NTA），绕过故障区域的 DNSSEC 验证。与过去不同的是，这次客户端不必只相信解析器运营方的公告：DNS 响应会携带 EDE 33，明确说明验证已被绕过。
这项变化没有消除 DNSSEC 故障，却让应急降级从不可见的内部策略，变成了客户端可以观测和审计的协议事件。
为什么一次密钥轮换会影响整个顶级域名
DNSSEC 依靠一条从根区向下延伸的信任链。父区发布 DS 记录，指向子区持有的 DNSKEY；子区再使用对应私钥为记录集生成 RRSIG。验证解析器会逐层检查这些记录，确认答案没有被篡改。
密钥轮换必须让父区 DS、子区 DNSKEY 和签名在正确的时间窗口内重叠。如果其中一步遗漏、顺序错误或传播尚未完成，解析器就可能得到一条无法验证的信任链。此时，即使权威服务器仍在正常返回 A、AAAA 或 NS 记录，严格执行 DNSSEC 的递归解析器也会把结果判为 bogus，并向客户端返回 SERVFAIL。
当问题发生在 .AL 这样的顶级域名时，影响范围不只是一台服务器或一个业务域名，而是该后缀下大量启用了委派的域名。普通用户看到的通常只是网页打不开、邮件投递失败或 API 连接超时，很难直接判断根因来自 DNSSEC。
NTA 恢复可用性，也引入了安全降级
负信任锚是一种有范围、有时限的应急措施。解析器运营方可以针对已确认发生 DNSSEC 配置事故的区域，暂时停止要求完整验证，从而继续返回普通 DNS 答案。
这能迅速恢复可用性，但代价必须说清楚：在 NTA 生效期间，受影响区域的答案不再获得原本预期的 DNSSEC 验证保障。NTA 不是“修好了 DNSSEC”，而是解析器判断短期可用性比继续阻断更重要。
因此，成熟的 NTA 操作至少需要具备以下约束：
- 只覆盖发生故障的最小区域，避免扩大验证绕过范围。
- 设置明确的到期时间，并持续检查权威侧是否已经修复。
- 记录启用原因、审批过程、影响范围和撤销时间。
- 向客户端暴露降级状态，让监控系统能够区分普通故障和安全策略变化。
最后一点正是 EDE 33 的价值所在。
EDE 33 把内部决策带进 DNS 响应
扩展 DNS 错误（Extended DNS Errors，EDE）通过 EDNS 在响应中携带比 SERVFAIL、NOERROR 更具体的诊断信息。此次 .AL 事件中，1.1.1.1 返回 EDE 33，用来表明 DNSSEC 验证已被绕过。
客户端因此可以区分三种语义完全不同的情况：
- 响应带有 AD（Authenticated Data）标志：解析器确认答案通过 DNSSEC 验证。
- 响应没有 AD，也没有相关 EDE：答案未被认证，但原因并不明确，也可能是区域本来就没有 DNSSEC。
- 响应携带 EDE 33：解析器明确告知客户端，它针对该答案绕过了原本应执行的验证。
需要注意，EDE 是诊断信号，不是新的加密证明。它描述递归解析器采取了什么策略，因此客户端仍然需要信任所使用的解析器以及到解析器的传输路径。使用 DoH、DoT 或受控网络可以降低响应在途中被修改的风险，但不能把 EDE 本身变成 DNSSEC 等价物。
用 dig 检查验证状态和 EDE
可以这样实践：安装较新的 BIND dig，向 1.1.1.1 查询目标区域，同时请求 DNSSEC 数据。将 al 替换成需要检查的域名。
#!/usr/bin/env bash
set -euo pipefail
name="${1:-al}"
resolver="${RESOLVER:-1.1.1.1}"
output="$(dig @"$resolver" "$name" SOA +dnssec +comments +multiline)"
printf '%s\n' "$output"
if printf '%s\n' "$output" | grep -Eqi 'EDE:[[:space:]]*33|EDE.*validation.*bypass'; then
printf 'WARNING: resolver reports DNSSEC validation bypass for %s\n' "$name" >&2
exit 2
fi
if printf '%s\n' "$output" | grep -Eq 'flags:.*[[:space:]]ad([[:space:]]|;)'; then
printf 'OK: resolver marked the answer as DNSSEC-authenticated\n'
else
printf 'NOTICE: no AD flag; the answer is not proven authenticated by this response\n' >&2
fi
保存为 check-dnssec.sh 后可以直接运行：
chmod +x check-dnssec.sh
./check-dnssec.sh al
RESOLVER=1.1.1.1 ./check-dnssec.sh example.com
这段脚本约定退出码 2 表示检测到验证绕过，适合接入 CI、探针或告警系统。由于 NTA 是临时措施，故障解除后再次查询 .AL 不一定还能看到 EDE 33。工具版本也很重要：旧版 dig 可能不会把 EDE 选项解码成人类可读的文本，此时应升级 BIND 工具，并保留原始响应做进一步分析。
生产监控不要只匹配一段英文说明文字。更稳妥的做法是解析 EDNS OPT 记录中的数字代码 33，同时记录查询名、解析器地址、响应码、AD/CD 标志和观测时间。文字内容适合展示，数字代码才适合自动化判断。
接入告警前要划清边界
EDE 33 让 DNSSEC 降级变得可观测，但客户端不能把它简单解释成“域名不安全”或“解析器被攻击”。它表示验证被有意绕过，原因可能是解析器运营方正在处置已经确认的权威侧事故。
落地时可以采用分级策略：普通终端记录事件但继续连接；内部服务提高告警级别；涉及软件更新、证书签发或密钥下载的高敏感流程，则可以拒绝依赖处于验证绕过状态的 DNS 答案。与此同时，应监控 EDE 33 的持续时间和影响域名数量。短期、局部的降级可能是合理应急，长期或大范围出现则需要立即追查。
这次变化最值得借鉴的并不是“用 NTA 保住解析”这一单独动作，而是把安全降级公开到协议响应中。可用性恢复只是事故处理的一半；让调用方知道恢复是以什么安全代价换来的，才使整个过程具备审计、告警和策略控制的基础。