导语

全球互联网基础设施的安全与透明度，是所有上层应用稳定运行的底座。近期两则分别来自产业实践与学术研究的进展，共同推动这一底座的能力再上台阶：Cloudflare在处置.AL顶级域名DNSSEC故障的过程中，首次落地了全新的EDE 33扩展错误码，解决了临时关闭DNSSEC校验的黑盒问题；arXiv新发表的分布式机密存储研究，则为网络环境下的敏感数据存储提供了兼顾抗毁与防泄露的量化优化框架。

事实综述

.AL域名故障推动DNS解析透明度突破

2026年7月3日，阿尔巴尼亚国家通信管理局（AKEP）作为.AL国家顶级域名的运维方，进行DNSSEC密钥轮转操作时出现流程错误：先是发布了新的DNSKEY并删除了旧密钥，但根区的DS记录仍然指向旧密钥，导致所有带DNSSEC校验的解析器都无法通过校验，返回SERVFAIL错误；之后运维方又错误地删除了新密钥却未恢复旧密钥，导致整个.AL zone没有可用的DNSKEY，故障进一步扩大。本次故障覆盖了所有.AL后缀的域名，包括阿尔巴尼亚的政府服务、银行、媒体等核心站点，Cloudflare的公共DNS服务1.1.1.1也受影响，用户无法访问任何.AL域名。

此前2026年5月德国.DE顶级域名也出现过类似的DNSSEC故障，当时Cloudflare的处置方案是添加负信任锚（NTA），临时跳过该域名的DNSSEC校验，优先恢复可用性，但该方案存在明显的安全短板：用户端收到的解析响应和正常校验通过的响应完全一致，无法获知当前响应并未经过DNSSEC校验，也就无法区分是合法响应还是被劫持的伪造响应，只能通过Cloudflare发布的公开状态页被动获知故障信息，时效性和透明度都极低。

在本次.AL故障处置中，Cloudflare首次落地了由Quad9和Cloudflare共同提交IETF的EDE 33扩展错误码标准：在添加NTA恢复解析的同时，所有.AL域名的解析响应都会携带EDE 33标记，明确告知客户端“当前响应因NTA生效未经过DNSSEC校验”，同时还会携带EDE 9标记说明底层故障原因是DNSKEY缺失。用户无需访问外部状态页，直接从DNS响应中就能获得完整的上下文信息，监控工具和应用也可以基于该标记自动调整安全策略。目前EDE 33已经获得IANA正式分配，kdig工具已经支持识别该错误码，Unbound解析器的适配PR正在审核中，相关标准草案已经提交IETF DNSOP工作组讨论。

分布式机密存储理论获突破性进展

来自arXiv的最新论文《Robust Secret Storage in Networks》提出了一套全新的分布式机密存储正式框架，解决了长期以来分布式存储场景中“抗毁性”和“抗攻击性”难以平衡的痛点：前者要求即使部分网络节点掉线、链路中断，用户仍然可以恢复存储的机密数据；后者要求即使部分节点被攻击者控制，也无法泄露完整的机密信息。该论文基于最小信息承载子图（MICS）推导了可生存性的精确表达式，并且设计了半本地优化方法，不需要掌握全局网络结构就能完成部署，特别适配去中心化网络、边缘网络等动态性较强的场景，甚至在极限场景下可以将鲁棒性函数映射为有效的自旋哈密顿量，可广泛应用于技术系统与社会系统的机密存储需求。

解读与评价

两项进展分别从产业落地和学术研究维度，补齐了互联网基础设施安全的两大核心短板。

首先看EDE 33的价值：DNSSEC作为保障域名解析安全的核心协议，此前一直存在“可用性和安全性二选一”的处置盲区：当顶级域名出现DNSSEC配置故障时，解析服务商要么选择坚持校验导致全站不可用，要么选择跳过校验但用户无法感知安全风险。EDE 33的出现打破了这个两难局面，在保障可用性的同时把安全状态的知情权交还给用户，未来随着全生态的适配，DNS解析的透明度将得到质的提升，域名劫持的风险将进一步降低。

再看分布式机密存储框架的价值：当前分布式存储领域无论是IPFS这类去中心化存储，还是云厂商的多可用区存储，在机密数据存储场景下都难以兼顾抗毁和防泄露的需求，往往需要牺牲一方来保障另一方。这套新框架给出了量化的优化方法，尤其是不需要全局网络知识的特性，非常适合国内正在快速发展的边缘计算、Web3、政务敏感数据存储等场景。

对中国开发者而言，做DNS工具、域名运维、网络监控的团队可以提前适配EDE 33错误码，优化告警策略，比如当收到EDE 33标记时，自动触发额外的安全校验逻辑，避免在故障期间遭受域名劫持攻击；域名运维团队也可以复盘.AL和.DE的故障案例，完善DNSSEC密钥轮转的流程规范，避免出现类似的全站故障；分布式存储、隐私计算领域的开发者则可以跟进该研究的后续落地进展，基于这套框架优化现有存储系统的安全能力，打造差异化的产品竞争力。