2026年7月3日，阿尔巴尼亚国家代码顶级域名（ TLD ）运营商阿尔巴尼亚通信管理局（ AKEP ）尝试进行DNSSEC密钥滚动。出错了，导致DNSSEC验证失败。DNSSEC规范要求接收这些签名的任何验证DNS解析器拒绝这些签名并将错误返回给客户端。其中包括由Cloudflare运营的公共DNS解析器1.1.1.1。
.AL顶级域名是阿尔巴尼亚政府服务、银行和媒体的在线主页；它在Cloudflare Radar的顶级域名排名中排名第191位。在事件发生期间，任何试图使用验证解决程序访问这些网站的人都无法联系到他们。该故障有可能影响每个.AL域，无论它托管在哪里或哪个权威名称服务器为其提供服务。就在两个月前，德国的顶级域名DE也发生了类似的事件。
正如我们在有关事件的博客文章中所述，我们的回应是为.DE安装负信任锚(NTA)，在1.1.1.1中暂停DNSSEC验证，以便在注册表解决问题时保持域可访问。我们也为.AL做了同样的事情。NTA恢复分辨率，但无提示。
根据NTA收到响应的客户端无法仅从响应中判断DNSSEC验证被绕过，使其无法区分合法答案和欺骗答案。对于.AL事件， 1.1.1.1首次填补了这一空白，返回了一个新的扩展DNS错误(EDE)代码以及每个受影响的响应，以表明由于存在NTA，答案未经DNSSEC验证。
下图显示了7月3日全年1.1.1.1上.AL查询的SERVFAIL和NOERROR率。随着缓存记录的到期和解析器被迫重新验证， SERVFAIL速率攀升。当在17:15 UTC应用NTA时，它会急剧下降，恢复分辨率。我们在之前的博客文章中更详细地讨论了DNSSEC的工作原理。简要回顾： DNSSEC构建从根区域到单个域名的信任链。