A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed

一次失败的 DNSSEC 密钥轮换导致 .AL 域名服务中断。现在 1.1.1.1 会告知你验证被绕过的情况

2026-07-14

• Sebastiaan Neuteboom

6 分钟阅读

2026 年 7 月 3 日，阿尔巴尼亚通信管理局（AKEP）尝试对阿尔巴尼亚国家代码顶级域名（.AL TLD）进行 DNSSEC 密钥轮换。事情出现了问题，导致 DNSSEC 验证失败。根据 DNSSEC 规范，任何接收到这些签名的验证 DNS 解析器都必须拒绝它们并向客户端返回错误。这包括由 Cloudflare 运营的公共 DNS 解析器 1.1.1.1。

.AL TLD 是阿尔巴尼亚政府服务、银行和媒体的在线家园，在 Cloudflare Radar 的 TLD 排名中位列第 191 位。在事件期间，任何使用验证解析器尝试访问这些网站的用户都会发现这些网站无法访问。此次故障有可能影响所有 .AL 域名，无论其托管位置或由哪些权威名称服务器提供服务。

就在两个月前，类似的事件发生在德国的 .DE TLD。正如我们在事件博客文章中所述，我们的应对措施是在 1.1.1.1 中安装了一个负信任锚（NTA），临时暂停 DNSSEC 验证，以保持域名在注册商解决问题期间的可访问性。我们对 .AL 采取了相同的措施。

NTA 恢复了解析，但悄无声息。客户端接收到由 NTA 提供的服务响应时，无法仅从响应本身判断 DNSSEC 验证是否被绕过，从而无法区分合法答案和伪造答案。对于 .AL 事件，1.1.1.1 首次解决了这一问题，返回了一个新的扩展 DNS 错误（EDE）代码，与每个受影响的响应一起，以表明由于 NTA 的存在，答案未经过 DNSSEC 验证。

下图显示了 7 月 3 日 1.1.1.1 上 .AL 查询的 SERVFAIL 和 NOERROR 率。随着缓存记录过期并迫使解析器重新验证，SERVFAIL 率上升。当 NTA 在 UTC 时间 17:15 应用时，SERVFAIL 率急剧下降，恢复了解析。

.AL 发生了什么

我们在之前的博客文章中详细讨论了 DNSSEC 的工作原理。简要回顾：

DNSSEC 从根区域向下构建到各个域名的信任链。根区域为每个已签名的 TLD 保存一个委托签名者（DS）记录，这是该 TLD 的 DNSKEY 的指纹。验证 .AL 的解析器会检查 .AL 的名称服务器提供的 DNSKEY 是否与根区域中的 DS 记录匹配。如果匹配，解析器会信任来自 .AL 名称服务器的 DNS 响应是真实的。同样的模式在下一级重复：.AL 为已签名的子区域保存 DS 记录，每个 DS 记录都有一个匹配的 DNSKEY。如果该链中的任何地方出现断裂，例如 DS 记录指向一个不再存在的密钥，那么所有下方的内容验证都会失败。

事件发生前，根区域保存了一个与 .AL 名称服务器提供的 DNSKEY 匹配的 DS 记录，如下图所示。

在 UTC 时间约 14:15，.AL 运营商发布了一个新的 DNSKEY 并停止提供旧的 DNSKEY。根区域中的 DS 记录仍然指向旧的 DNSKEY（id=26319），因此任何尝试验证 .AL 响应的解析器都找不到匹配的密钥并失败。

在 UTC 时间约 17:00，.AL 运营商删除了新的 DNSKEY 而没有恢复旧的 DNSKEY。现在区域中没有任何 DNSKEY 记录，而根区域中的 DS 记录仍然指向 id=26319，解析继续失败。

大约在UTC时间19:15，.AL域名注册机构从根区域中移除了DS记录。没有DS记录后，解析器不再期待对.AL域名进行DNSSEC验证，解析功能得以恢复，但此时整个顶级域已变为未签名状态。

截至发布时，.AL域名仍处于未签名状态。.AL注册机构尚未将DS记录重新添加到根区域。没有DS记录意味着每个.AL域名都无法使用DNSSEC保护。

为何使用负信任锚点

DNSSEC配置出现故障会带来严重后果，尤其是当整个顶级域同时受到影响时。正如我们在.DE事件博客中所讨论的，递归DNS运营商可以按照RFC 7646的定义安装负信任锚点（Negative Trust Anchor，NTA），这会指示解析器将某个区域视为未签名并绕过验证。

在安装NTA之前，我们尝试直接联系.AL注册机构，并在DNS-OARC Mattermost上发帖通知社区。我们未收到任何回应，部分原因是注册机构的联系方式本身属于.AL域名，在服务中断期间导致无法联系。

我们在UTC时间17:15（链断裂后约3小时）为.AL安装了NTA，并将其部署到所有1.1.1.1用户。

取舍与.DE事件相同：负信任锚点会暂停DNSSEC验证，这意味着在暂停期间.AL域名不再能抵御DNS欺骗攻击。我们认为这种取舍是可接受的，原因与.DE事件相同：故障是公开、已确认且对所有验证解析器造成同等影响。

在次日.AL注册机构将DS记录从根区域移除后，负信任锚点被删除。由于没有DS记录存在，解析器不再期待.AL的DNSSEC验证，NTA也变得不再需要。

负信任锚点的问题

安装负信任锚点是一种激进的措施。我们暂停DNSSEC验证以确保域名可达，接受在此期间响应不再经过密码学验证的事实。用户会收到答案而非SERVFAIL，但这些答案不携带任何DNSSEC保证。

更困难的是，直到现在，DNS响应中没有任何内容会向客户端发出这一信号；在NTA下提供的响应与完全验证过的响应看起来完全相同。RFC 7646承认这一缺陷，建议运营商公开披露已部署的NTA，但这种披露是带外进行的。在.DE和.AL事件中，我们均发布了状态页面，但状态页面需要用户主动查看。应用程序、监控工具或查询1.1.1.1的用户无法仅从响应本身判断DNSSEC验证是否被绕过。

为负信任锚点带来透明度

RFC 8914定义的扩展DNS错误（EDE）代码允许解析器在任何DNS响应（无论是错误还是成功答案）中包含附加上下文信息。Quad9的Babak Farrokhi提出了一个互联网草案，建议通过新的EDE代码在DNS响应中直接表明负信任锚点的存在：DNS响应中负信任锚点的披露。我们作为联合作者参与了该草案，目前1.1.1.1已实现该功能。

在.AL事件期间，当负信任锚点已安装时，任何对.AL域名的查询都会同时返回答案和新的EDE代码。以下是具体示例：

$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS 伪区域： ;; 版本：0；标志：；UDP 大小：1232 B；扩展错误代码：NOERROR ;; EDE：9（DNSKEY 缺失）：'未找到与 DS 匹配的 SEP（安全入口点）用于 al.' ;; EDE：33（负信任锚）：'已为此次查询应用了负信任锚（详见 RFC 7646）'

;; 答案区域： google.al. 300 IN A 142.251.142.196

该响应为 NOERROR 且包含有效答案：google.al 可解析，但伴随两个 EDE 错误代码。EDE 9（DNSKEY 缺失）揭示了底层的 DNSSEC 失败：信任链被打破且验证失败。EDE 33（负信任锚）表明 1.1.1.1 应用了负信任锚并仍然返回了响应。两者共同为客户端和运营商提供了完整可见性：答案真实有效，但未通过 DNSSEC 验证。

当负信任锚（NTA）处于激活状态时，1.1.1.1 会向所有生成的响应返回 EDE 33，无论查询本身是否会导致 DNSSEC 验证失败。即使某个域名完全未使用 DNSSEC，只要其处于活跃的 NTA 覆盖范围内，仍会携带 EDE 33。这是有意为之：NTA 覆盖整个区域，透明性原则适用于所有在此范围内返回的响应。

这也解决了我们在 .DE 博客中指出的问题，即 1.1.1.1 错误地返回了 EDE 22（无可达权威服务器）而非揭示底层的 DNSSEC 错误。在 .AL 事件中，1.1.1.1 正确返回了 EDE 9（DNSKEY 缺失）和 EDE 33。

该互联网草案为个人提交，EDE 33 已由互联网号码分配机构（IANA）分配。得益于我们的合著者 Quad9 的 Babak Farrokhi，Knot 项目中的 kdig 工具现已能通过名称识别 EDE 33，Unbound 的拉取请求正在审核中。我们希望其他解析器实现也能跟进。该互联网草案已提交至互联网工程任务组（IETF）DNSOP 工作组，并将在 7 月 18 日至 24 日于维也纳举行的 IETF 会议中进行讨论。

### 修复缺口

顶级域名（TLD）级别的 DNSSEC 失败较为罕见，但一旦发生，将同时影响该 TLD 下所有子域名，并对所有验证解析器造成同等影响。.AL 事件紧随 .DE 事件之后，表明负信任锚是一种必要的运营工具，但此前对受影响用户而言是不可见的。

EDE 33 修复了 RFC 7646 留下的缺口。现在，通过负信任锚返回的响应会直接表明这一点，为运营商、监控工具和用户提供了所需的信息，以理解解析器的行为及其原因。

该互联网草案可在 IETF 数据跟踪器上获取。如果您对此有意见，IETF DNSOP 邮件列表是分享观点的正确渠道。

如果想了解更多关于 DNSSEC 的工作原理，请访问我们的页面 [How does DNSSEC work?](https://example.com)。您还可以随时通过 [Cloudflare Radar](https://example.com) 实时跟踪 DNS 趋势和 TLD 数据。

[if astro]>server-island-start<![endif]

DNS

DNSSEC

事故回顾

1.1.1.1

可靠性

标准