阿尔巴尼亚的DNSSEC密钥更换失败导致.AL域名宕机。现在1.1.1.1会告诉你何时绕过验证
2026年7月3日，阿尔巴尼亚通信局 (AKEP)，该国代码顶级域 (TLD) 的运营商，尝试进行了DNSSEC密钥更换。但不幸的是，发生了故障，导致DNSSEC验证失败。根据DNSSEC规范，任何接收到这些签名的验证DNS解析器都必须拒绝它们并向客户端返回错误。这包括[1.1.1.1](https://www.cloudflare.com/learning/dns/what-is-1.1.1.1/)，这是由Cloudflare运营的公共DNS解析器。
**.AL** TLD 是阿尔巴尼亚政府服务、银行和媒体的在线门户网站；它在Cloudflare雷达的TLD排名中位列[第191](https://radar.cloudflare.com/tlds/al?dateRange=7d)。在事件发生期间，任何尝试使用验证解析器访问这些网站的用户都发现它们无法访问。这一失败可能会影响到每个**.AL** 域名，无论它们托管在哪里或使用哪些权威名称服务器。
就在两个月前，类似的事件发生在德国的**.DE**上。如我们在[关于该事件的博文](https://blog.cloudflare.com/de-tld-outage-dnssec/)中描述的那样，我们的应对措施是为**.DE**安装负信任锚（NTA），暂时暂停1.1.1.1的DNSSEC验证，以确保域名可以访问，同时注册机构解决问题。我们对**.AL**也采取了同样的措施。
NTA能够恢复解析，但并不明显。收到NTA响应的客户端无法仅凭响应判断DNSSEC验证是否被绕过，因此无法区分合法答案和欺骗答案。在**.AL**事件中，1.1.1.1首次对此漏洞进行了修复，在每个受影响的响应中返回一个新的扩展DNS错误（EDE）代码，以表示由于存在NTA，答案没有经过DNSSEC验证。
下面的图展示了2026年7月3日1.1.1.1的**.AL**查询的SERVFAIL和NOERROR率。随着缓存记录过期，SERVFAIL率上升，一旦在17:15 UTC应用了NTA，SERVFAIL率则急剧下降，解析得以恢复。
### .AL发生了什么？
我们在[之前的博文中更详细地讨论了DNSSEC的工作原理](https://blog.cloudflare.com/de-tld-outage-dnssec/#how-dnssec-works)。简要回顾：DNSSEC从根区建立了一条信任链，到达单独的域名。根区为每个已签名的TLD持有一个委托签名（DS）记录，这是该TLD的DNSKEY的指纹。验证**.AL**的解析器检查**.AL**的名称服务器提供的DNSKEY是否与根中的DS记录匹配。如果匹配，则解析器信任来自**.AL**名称服务器的DNS响应是可信的。相同的模式在下一级重复：**.AL**为其已签名的子区持有DS记录，每个子区都有一个匹配的DNSKEY。链中的任何断裂，比如指向不再存在的密钥的DS记录，会导致其下的所有内容验证失败。
在事件发生之前，根区持有一条与**.AL**名称服务器提供的DNSKEY匹配的DS记录，如下图所示。
在大约14:15 UTC，**.AL**运营商发布了新的DNSKEY，并停止服务旧的DNSKEY。根区中的DS记录仍指向旧的DNSKEY (id=26319)，因此任何尝试验证**.AL**响应的解析器都无法找到匹配的密钥，并因此失败。
在大约17:00 UTC，**.AL**运营商删除了新的DNSKEY，而没有恢复旧的DNSKEY。此时，区域中根本没有DNSKEY记录，而根中的DS记录仍指向id=26319，解析仍然失败。
在大约19:15 UTC，**.AL**运营商从根区中删除了DS记录。没有DS记录，解析器不再期待**.AL**的DNSSEC验证，解析得以恢复，尽管整个TLD现在已经失去签名。
截至发稿时，**.AL**仍然没有签名。**.AL**运营商尚未将DS记录恢复到根区。在没有DS记录的情况下，每个**.AL**域名都无法使用DNSSEC保护。
### 为什么使用负信任锚
一个错误的DNSSEC配置可能非常棘手，尤其是当它影响整个TLD时。如我们在[关于**.DE**事件的博文](https://blog.cloudflare.com/de-tld-outage-dnssec/#negative-trust-anchors)中提到的，递归DNS运营商可以安装负信任锚（NTA），如[ RFC 7646](https://datatracker.ietf.org/doc/html/rfc7646)所定义，这将指示解析器将区域视为未签名，因此绕过验证。
在安装NTA之前，我们尝试直接联系**.AL**的运营商，并在[DNS-OARC Mattermost](https://www.dns-oarc.net/oarc/services/chat)上发布内容以提醒社区。我们没有收到回应，部分原因是运营商的联系地址本身就在**.AL**下，这使得在故障期间无法联络。
我们为**.AL**应用了NTA，并在17:15 UTC向所有1.1.1.1用户推出，大约是在链路中断后三小时。
这样的权衡与**.DE**时相同：负信任锚暂停DNSSEC验证，这意味着**.AL**域名在期间内不再受到DNS欺骗保护。我们认为这是可以接受的，原因相同：故障是公开的，已确认，并同样影响每个验证解析器。
负信任锚在次日被删除，一旦**.AL**运营商已从根区中删除DS记录。没有DS记录，解析器不再期待**.AL**的DNSSEC，NTA也变得不再需要。
### 负信任锚的问题
安装负信任锚是一项激进的措施。我们暂停DNSSEC验证以保持域名可访问，接受在此期间响应不再经过密码学验证。用户得到答案，而不是SERVFAIL，但这些答案没有DNSSEC保证。
更困难的是，直到现在，DNS响应中没有任何内容向客户表明这一点；在 NTA 下提供的响应与完全验证的响应看起来完全相同。RFC 7646承认了这一漏洞，并建议运营商公开披露他们所采用的NTAs，但这种披露是在带外进行的。对于[**.DE**](https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz)与[**.AL**](https://www.cloudflarestatus.com/incidents/64d6d3l2h1lt)事件，我们发布了状态页面，但状态页面需要用户主动查看。应用程序、监控工具或查询1.1.1.1的用户无法仅凭响应判断DNSSEC验证是否被绕过。
### 让负信任锚更透明
扩展DNS错误（EDE）代码，（如[ RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914)所定义）允许解析器在任何DNS响应中包括额外的上下文，无论是错误还是成功的答案。来自Quad9的Babak Farrokhi提议了一项互联网草案，直接在DNS响应中指示负信任锚的存在，使用一种新的EDE代码：[**Disclosure of Negative Trust Anchors in DNS Responses**](https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ede-nta/)。我们加入了作为共同作者，1.1.1.1现在已实现该功能。
在**.AL**事件期间，对于任何**.AL**名称的查询在安装负信任锚时返回了答案和新的EDE代码。以下是查询样本：
```shell
$ 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 PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
```
这个响应是NOERROR且有有效的答案：**google.al**解析成功，但有两个EDE代码伴随其后。EDE 9 (DNSKEY Missing)呈现了潜在的DNSSEC故障：信任链已断裂，验证失败。EDE 33 (Negative Trust Anchor)则表明1.1.1.1已应用负信任锚，并且任然返回了响应。它们合在一起，给客户和运营商提供了对发生事件的全面了解：答案真实，但并未通过DNSSEC验证。
1.1.1.1在NTA处于活动状态时，对任何响应返回EDE 33，无论查询本身是否会失败DNSSEC验证。对于一个完全不使用DNSSEC的域名，如果它处于一个活动的NTA下，仍然将携带EDE 33。这是出于意图：NTA覆盖整个区域，透明性同样适用于它下的每个响应。
这同时解决了我们在**.DE**博客中提到的问题，在那里1.1.1.1错误地返回了EDE 22 (No Reachable Authority)，而没有展示潜在的DNSSEC错误。在**.AL**事件中，1.1.1.1正确地返回了EDE 9 (DNSKEY Missing)和EDE 33。
该互联网草案是个人提交的，EDE 33已经由[互联网号码分配局（IANA）](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes)授予。感谢我们共同作者Babak Farrokhi，Knot项目的[kdig](https://www.knot-dns.cz/docs/latest/html/man_kdig.html)工具现在[认出EDE 33](https://github.com/CZ-NIC/knot/commit/1b053bcfe17eaa4f008d589d6ec0ea53145e22e4)，而[a pull request for Unbound](https://github.com/NLnetLabs/unbound/pull/1470)正在审查中。我们希望其他解析器实现能跟进。该互联网草案已提交给[互联网工程任务组（IETF）DNSOP工作组](https://datatracker.ietf.org/wg/dnsop/about/)，并将在7月18日至24日的维也纳IETF会议上讨论。
### 填补空白
TLD级别的DNSSEC故障是罕见的，但一旦发生，它们会同时影响每个在受影响TLD下的域名，以及每个验证解析器。**.AL**事件，紧随**.DE**之后，表明负信任锚是一个必要的操作工具，但到目前为止，对受影响的用户来说仍然是不可见的。
EDE 33填补了RFC 7646留下的空白。在负信任锚下提供的响应现在直接说明了这一点，给予运营商、监控工具和用户他们所需的信息，以理解解析器所做的事情及其原因。
如果你想了解更多关于DNSSEC工作原理的信息，请访问我们页面[《DNSSEC是如何工作的？》](https://www.cloudflare.com/en-gb/learning/dns/dnssec/how-dnssec-works/)。你也可以随时在[Cloudflare Radar](https://radar.cloudflare.com/tlds/al?dateStart=2026-07-03&dateEnd=2026-07-03)上关注实时的DNS趋势和TLD数据。
---
原文链接：[点击查看](https://blog.cloudflare.com/dnssec-nta-ede-33/)
**.AL** TLD 是阿尔巴尼亚政府服务、银行和媒体的在线门户网站；它在Cloudflare雷达的TLD排名中位列[第191](https://radar.cloudflare.com/tlds/al?dateRange=7d)。在事件发生期间，任何尝试使用验证解析器访问这些网站的用户都发现它们无法访问。这一失败可能会影响到每个**.AL** 域名，无论它们托管在哪里或使用哪些权威名称服务器。
就在两个月前，类似的事件发生在德国的**.DE**上。如我们在[关于该事件的博文](https://blog.cloudflare.com/de-tld-outage-dnssec/)中描述的那样，我们的应对措施是为**.DE**安装负信任锚（NTA），暂时暂停1.1.1.1的DNSSEC验证，以确保域名可以访问，同时注册机构解决问题。我们对**.AL**也采取了同样的措施。
NTA能够恢复解析，但并不明显。收到NTA响应的客户端无法仅凭响应判断DNSSEC验证是否被绕过，因此无法区分合法答案和欺骗答案。在**.AL**事件中，1.1.1.1首次对此漏洞进行了修复，在每个受影响的响应中返回一个新的扩展DNS错误（EDE）代码，以表示由于存在NTA，答案没有经过DNSSEC验证。
下面的图展示了2026年7月3日1.1.1.1的**.AL**查询的SERVFAIL和NOERROR率。随着缓存记录过期，SERVFAIL率上升，一旦在17:15 UTC应用了NTA，SERVFAIL率则急剧下降，解析得以恢复。
### .AL发生了什么？
我们在[之前的博文中更详细地讨论了DNSSEC的工作原理](https://blog.cloudflare.com/de-tld-outage-dnssec/#how-dnssec-works)。简要回顾：DNSSEC从根区建立了一条信任链，到达单独的域名。根区为每个已签名的TLD持有一个委托签名（DS）记录，这是该TLD的DNSKEY的指纹。验证**.AL**的解析器检查**.AL**的名称服务器提供的DNSKEY是否与根中的DS记录匹配。如果匹配，则解析器信任来自**.AL**名称服务器的DNS响应是可信的。相同的模式在下一级重复：**.AL**为其已签名的子区持有DS记录，每个子区都有一个匹配的DNSKEY。链中的任何断裂，比如指向不再存在的密钥的DS记录，会导致其下的所有内容验证失败。
在事件发生之前，根区持有一条与**.AL**名称服务器提供的DNSKEY匹配的DS记录，如下图所示。
在大约14:15 UTC，**.AL**运营商发布了新的DNSKEY，并停止服务旧的DNSKEY。根区中的DS记录仍指向旧的DNSKEY (id=26319)，因此任何尝试验证**.AL**响应的解析器都无法找到匹配的密钥，并因此失败。
在大约17:00 UTC，**.AL**运营商删除了新的DNSKEY，而没有恢复旧的DNSKEY。此时，区域中根本没有DNSKEY记录，而根中的DS记录仍指向id=26319，解析仍然失败。
在大约19:15 UTC，**.AL**运营商从根区中删除了DS记录。没有DS记录，解析器不再期待**.AL**的DNSSEC验证，解析得以恢复，尽管整个TLD现在已经失去签名。
截至发稿时，**.AL**仍然没有签名。**.AL**运营商尚未将DS记录恢复到根区。在没有DS记录的情况下，每个**.AL**域名都无法使用DNSSEC保护。
### 为什么使用负信任锚
一个错误的DNSSEC配置可能非常棘手，尤其是当它影响整个TLD时。如我们在[关于**.DE**事件的博文](https://blog.cloudflare.com/de-tld-outage-dnssec/#negative-trust-anchors)中提到的，递归DNS运营商可以安装负信任锚（NTA），如[ RFC 7646](https://datatracker.ietf.org/doc/html/rfc7646)所定义，这将指示解析器将区域视为未签名，因此绕过验证。
在安装NTA之前，我们尝试直接联系**.AL**的运营商，并在[DNS-OARC Mattermost](https://www.dns-oarc.net/oarc/services/chat)上发布内容以提醒社区。我们没有收到回应，部分原因是运营商的联系地址本身就在**.AL**下，这使得在故障期间无法联络。
我们为**.AL**应用了NTA，并在17:15 UTC向所有1.1.1.1用户推出，大约是在链路中断后三小时。
这样的权衡与**.DE**时相同：负信任锚暂停DNSSEC验证，这意味着**.AL**域名在期间内不再受到DNS欺骗保护。我们认为这是可以接受的，原因相同：故障是公开的，已确认，并同样影响每个验证解析器。
负信任锚在次日被删除，一旦**.AL**运营商已从根区中删除DS记录。没有DS记录，解析器不再期待**.AL**的DNSSEC，NTA也变得不再需要。
### 负信任锚的问题
安装负信任锚是一项激进的措施。我们暂停DNSSEC验证以保持域名可访问，接受在此期间响应不再经过密码学验证。用户得到答案，而不是SERVFAIL，但这些答案没有DNSSEC保证。
更困难的是，直到现在，DNS响应中没有任何内容向客户表明这一点；在 NTA 下提供的响应与完全验证的响应看起来完全相同。RFC 7646承认了这一漏洞，并建议运营商公开披露他们所采用的NTAs，但这种披露是在带外进行的。对于[**.DE**](https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz)与[**.AL**](https://www.cloudflarestatus.com/incidents/64d6d3l2h1lt)事件，我们发布了状态页面，但状态页面需要用户主动查看。应用程序、监控工具或查询1.1.1.1的用户无法仅凭响应判断DNSSEC验证是否被绕过。
### 让负信任锚更透明
扩展DNS错误（EDE）代码，（如[ RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914)所定义）允许解析器在任何DNS响应中包括额外的上下文，无论是错误还是成功的答案。来自Quad9的Babak Farrokhi提议了一项互联网草案，直接在DNS响应中指示负信任锚的存在，使用一种新的EDE代码：[**Disclosure of Negative Trust Anchors in DNS Responses**](https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ede-nta/)。我们加入了作为共同作者，1.1.1.1现在已实现该功能。
在**.AL**事件期间，对于任何**.AL**名称的查询在安装负信任锚时返回了答案和新的EDE代码。以下是查询样本：
```shell
$ 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 PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
```
这个响应是NOERROR且有有效的答案：**google.al**解析成功，但有两个EDE代码伴随其后。EDE 9 (DNSKEY Missing)呈现了潜在的DNSSEC故障：信任链已断裂，验证失败。EDE 33 (Negative Trust Anchor)则表明1.1.1.1已应用负信任锚，并且任然返回了响应。它们合在一起，给客户和运营商提供了对发生事件的全面了解：答案真实，但并未通过DNSSEC验证。
1.1.1.1在NTA处于活动状态时，对任何响应返回EDE 33，无论查询本身是否会失败DNSSEC验证。对于一个完全不使用DNSSEC的域名，如果它处于一个活动的NTA下，仍然将携带EDE 33。这是出于意图：NTA覆盖整个区域，透明性同样适用于它下的每个响应。
这同时解决了我们在**.DE**博客中提到的问题，在那里1.1.1.1错误地返回了EDE 22 (No Reachable Authority)，而没有展示潜在的DNSSEC错误。在**.AL**事件中，1.1.1.1正确地返回了EDE 9 (DNSKEY Missing)和EDE 33。
该互联网草案是个人提交的，EDE 33已经由[互联网号码分配局（IANA）](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes)授予。感谢我们共同作者Babak Farrokhi，Knot项目的[kdig](https://www.knot-dns.cz/docs/latest/html/man_kdig.html)工具现在[认出EDE 33](https://github.com/CZ-NIC/knot/commit/1b053bcfe17eaa4f008d589d6ec0ea53145e22e4)，而[a pull request for Unbound](https://github.com/NLnetLabs/unbound/pull/1470)正在审查中。我们希望其他解析器实现能跟进。该互联网草案已提交给[互联网工程任务组（IETF）DNSOP工作组](https://datatracker.ietf.org/wg/dnsop/about/)，并将在7月18日至24日的维也纳IETF会议上讨论。
### 填补空白
TLD级别的DNSSEC故障是罕见的，但一旦发生，它们会同时影响每个在受影响TLD下的域名，以及每个验证解析器。**.AL**事件，紧随**.DE**之后，表明负信任锚是一个必要的操作工具，但到目前为止，对受影响的用户来说仍然是不可见的。
EDE 33填补了RFC 7646留下的空白。在负信任锚下提供的响应现在直接说明了这一点，给予运营商、监控工具和用户他们所需的信息，以理解解析器所做的事情及其原因。
如果你想了解更多关于DNSSEC工作原理的信息，请访问我们页面[《DNSSEC是如何工作的？》](https://www.cloudflare.com/en-gb/learning/dns/dnssec/how-dnssec-works/)。你也可以随时在[Cloudflare Radar](https://radar.cloudflare.com/tlds/al?dateStart=2026-07-03&dateEnd=2026-07-03)上关注实时的DNS趋势和TLD数据。
---
原文链接：[点击查看](https://blog.cloudflare.com/dnssec-nta-ede-33/)
评论
暂无评论。