Cloudflare：.al 的 DNSSEC rollover 故障致中断，1.1.1.1 以 EDE 33 提示验证被绕过

一、.al 发生了什么

2026 年 7 月 3 日，阿尔巴尼亚通信管理局 AKEP（.al 国家顶级域运营方）尝试 DNSSEC 密钥轮转，结果出错导致 DNSSEC 验证失败。任何验证解析器（含 Cloudflare 运营的 1.1.1.1）按规范必须拒绝这些签名并向客户端报错。.al 是阿尔巴尼亚政府、银行与媒体的在线家园，使用验证解析器的用户在整个事件中无法访问这些站点，且可能影响每一个 .al 域名。约两个月前 .de 顶级域发生过类似事故。

二、故障时间线

约 14:15 UTC，.al 运营方发布新 DNSKEY 并停止服务旧密钥，而根区 DS 记录仍指向旧 DNSKEY（id=26319），验证失败。约 17:00 UTC，运营方删除新 DNSKEY 却未恢复旧密钥，全域无任何 DNSKEY，解析继续失败。约 19:15 UTC，运营方从根区移除 DS 记录，解析恢复，但整个 TLD 自此处于未签名状态；截至发稿 .al 仍未将 DS 记录恢复至根区，所有 .al 域名无法使用 DNSSEC 保护。Cloudflare 在链断裂约三小时后（17:15 UTC）将 NTA 推广至全部 1.1.1.1 用户。

三、负信任锚（NTA）及其透明度缺口

递归解析运营方可按 RFC 7646 安装 Negative Trust Anchor（NTA），将某区域视为未签名并绕过验证以恢复可达性。代价是 .al 在期间不再受 DNS 欺骗保护。问题在于：NTA 下返回的响应与完全验证的响应看起来一模一样，客户端无从得知验证被绕过——RFC 7646 仅建议带外公开披露。1.1.1.1 在 .al 事件中首次实现了 Babak Farrokhi（Quad9）提出的互联网草案：用新 EDE 33（Negative Trust Anchor） 代码随每个受影响响应返回，表明该答案因 NTA 而未做 DNSSEC 验证（IANA 已分配该码）。

四、运维启示

查询 google.al 会同时得到答案与两条 EDE：EDE 9 (DNSKEY Missing) 暴露底层 DNSSEC 失败（信任链断裂），EDE 33 (Negative Trust Anchor) 表明 1.1.1.1 应用了 NTA 仍返回响应——客户端由此获完整可见性：答案真实，但未经 DNSSEC 验证。TLD 级 DNSSEC 故障虽罕见，一旦发生会同时影响该 TLD 下所有域名与所有验证解析器。运维方应在 DNSSEC 轮转前充分演练 KSK/ZSK 流程、保留回滚路径，并关注 EDE 33 等透明度信号以快速判断解析状态；该草案已提交 IETF DNSOP 工作组。

了解更多行业资讯，请访问 行业资讯首页 或致电 021-69753778 获取安全咨询服务。

相关文章

• 安全威胁分类总览

—— ztpop.net 编辑团队 译