北京
“我们首次在受影响响应中加入扩展DNS错误（EDE）代码，表明因负信任锚点而跳过验证。”Cloudflare在关于.AL事件的技术博客中这样写道。2026年7月3日，阿尔巴尼亚通讯管理局（AKEP）在对其国家顶级域名.AL进行DNSSEC密钥轮换时出现失误，导致整个.AL域下的所有网站对使用验证解析器的用户瞬间不可达。这场故障不仅暴露出DNSSEC链式信任的脆弱一面，也让一个长期被忽视的问题浮出水面：当解析器为了让网站恢复访问而偷偷绕过安全验证时，客户端其实毫不知情。
故障大约发生在世界协调时14时15分。当时，AKEP发布了新的DNSSEC密钥，却停止了旧密钥的提供。而根区中指向.AL的委派签名者（DS）记录仍然保留着旧密钥的指纹（密钥ID为26319）。按照DNSSEC规范，任何验证解析器在查询.AL域名时，都会发现.AL的域名服务器返回的DNSKEY与根区的DS记录不匹配。此时，解析器必须拒绝这些响应，并向客户端返回SERVFAIL错误。于是，所有依赖1.1.1.1这类验证解析器的用户，无论是想访问阿尔巴尼亚的政府服务、银行网站还是当地媒体，都只能看到“无法访问”的提示。
Cloudflare Radar的排名显示，.AL在全球顶级域名中位列第191位。虽然规模远不及.com或.de，但故障的冲击却不分体量——DNSSEC验证失败的链条一旦断裂，它下面的所有子域都会集体失效，不论这些网站实际托管在哪里，也不论它们自己的权威域名服务器是否运行正常。这并不是一个可以局部隔离的事故。仅仅两个月前，德国国家顶级域名.DE就遭遇了一次类似的DNSSEC故障，当时1.1.1.1采用了安装负信任锚点（NTA）的方法，暂时放弃对.DE域的验证，以此保持解析可达。在.AL故障中，1.1.1.1采取了相同的策略。
负信任锚点的确可以快速恢复解析，但在透明性上存在明显缺陷。由于DNS协议本身的约束，客户端收到的响应中没有任何字段能告诉它：“这条记录是解析器为你绕过DNSSEC验证得来的，可能已被劫持”。这意味着接收方无法区分正常的、经过链式验证的真实应答与可能被伪造的应答。对于依赖DNSSEC来防范缓存投毒和中间人攻击的服务来说，这种静默绕过无异于在安全门禁上贴了一张“临时禁用”的告示，却没有告诉任何刷卡的人。Cloudflare在.AL事件中首次尝试弥补了这一信息缺口。它利用扩展DNS错误（EDE）机制，在每一个因NTA而放行的响应中附加了错误代码，明确标示出该回答未经DNSSEC验证。
从1.1.1.1在7月3日全天的统计数据中可以清晰地看到这一变化的影响。在故障发生后，随着缓存的旧记录逐渐过期，解析器被迫重新验证，.AL查询的SERVFAIL率迅速攀升。世界协调时17时15分，负信任锚点生效，SERVFAIL率急剧下降，NOERROR（正常响应）率相应回升。但与以往.DE事件不同的是，这一次每一个被恢复的响应都带上了EDE错误标识，使下游系统和应用开发者第一次有机会根据这个标识采取额外措施，比如触发告警、拒绝缓存或记录安全事件。
DNSSEC的信任链结构决定了这类故障几乎不可能被根区之上的层级自动消化。根区持有每个已签名顶级域名的DS记录，它相当于一把指纹锁；顶级域的DNSKEY则如同那把必须匹配的钥匙。当.AL操作者替换了钥匙却忘了更新根区的指纹，所有试图沿着根一路验证下来的解析器都会在.AL这一层撞上一扇死锁的门。理解这一点，也就理解了为什么仅仅一层的密钥失误就能让整个国家域名的互联网可见性瞬间归零。而1.1.1.1此次加入的错误信号，并不是修复了信任链，而是让信任的暂时断裂变得可见——在安全领域，可见性本身往往就是一种修补。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
