摘要

  • ZARC 的公开事件复盘称，2025 年 3 月 6 日至 14 日，.ZA 商业二级域名受到 DNS 中断和退化影响 [1]。
  • ZADNA 的声明称 .za 命名空间发生服务中断，尤其涉及 co.za 名称，并确认 ZARC 运营 co.za、org.za、net.za 和 web.za 等商业二级域名 [2][3]。
  • ZADNA 提到流向名称服务器的异常流量、自动安全措施、涉及 Google Public DNS 的报告、缓解步骤以及容量与韧性后续工作 [2][3]。
  • IANA 根区数据库和 RFC 1034 把机制定位在 DNS、注册局与委派层，但它们不是 3 月事件本身的证据 [4][5]。
  • 问责重点是运营方和监督机构能否限定影响范围、解释缓解动作、保留不确定性，并说明哪些连续性控制发生了改变。

发生了什么

ZARC 后来发布 2025 年 3 月 DNS 中断与退化的公开复盘，影响对象被限定为 .ZA 商业二级域名。ZARC 表示，它分析了运行遥测，并在基础设施、运维、DNS 架构、程序和韧性方面实施改进 [1]。

ZADNA 3 月 14 日的声明提供了公共监督视角。声明说 .za 命名空间出现服务中断，特别点名 co.za，并确认 ZARC 是 co.za、org.za、net.za 和 web.za 等商业二级域名的注册局运营方 [2][3]。

ZADNA 还描述了事件的运行形态：名称服务器收到异常流量，自动安全措施介入，团队实施缓解，并出现涉及 Google Public DNS、可能影响域名解析的报告 [2][3]。这些证据足以把事件归入注册局 DNS 连续性问题，却不足以证明 Google 导致事件、整个 .za 全部失效，或完整根因已经公开。

这种窄口径很重要。注册局 DNS 事件不等于全国互联网完全中断。它影响的是让用户和软件找到服务的名称查询层。对于依赖相关域名的企业，结果仍然直接：名称不能稳定解析，服务看起来无法到达，即使托管系统本身正常。

为什么重要

注册局是记录维护者，也是运行基础设施的一部分。用户不是通过阅读政策文件访问域名，而是让软件查询 DNS。权威查询链路一旦退化，注册局的连续性控制就成为公共依赖。

这也是本文的 Heng.lu 表面：DNS、注册局和委派。记录准确仍不够；如果运行中的查询服务不能承受流量压力、缓解决策或解析器可见的异常，依赖者仍会失去可达性。问题不在于把注册局视为主权机构，而在于运行代码、记录、名称服务器、监控和恢复流程能否维持现实世界的连通。

事件还说明，透明度必须区分观察与推断。ZARC 可以报告遥测分析和改进 [1]；ZADNA 可以报告异常流量、自动措施和缓解后续 [2][3]。读者仍需知道哪些是权威 DNS 行为，哪些是递归解析器可见症状，哪些与容量有关，哪些来自自动防御，以及哪些事实尚未公开。

技术层

DNS 在委派层级中解析名称。IANA 的根区数据库列出 .za，确定其顶级域委派表面 [4]。RFC 1034 描述分布式名称系统：服务器回答名称查询，并在区域之间委派权威 [5]。这些来源解释为什么该事件属于 DNS 注册局层，不证明事件细节。

简化来说，递归解析器沿权威信息寻找答案。注册局及其名称服务器是这条链的一部分。流量处理、缓解策略或 DNS 架构如果退化，用户会看到域名解析失败，即使底层网站依旧在线。

ZARC 与 ZADNA 的材料指向同一运行类别：商业二级域名中断或退化、名称服务器异常流量、自动安全措施、缓解及韧性改进 [1][2][3]。材料没有公开所有内部日志、规则阈值、架构图或解析路径，本文的证据边界也停在这里。

谁受到影响

最稳妥的范围是依赖相关 .ZA 商业二级域名的用户、注册人和组织。ZADNA 明确提到 co.za，并描述 ZARC 运营的商业二级域名集合 [2][3]。

另一个受影响群体是服务看似宕机的运营方。应用、托管商或接入网络可能健康，但注册局 DNS 退化会制造面向客户的不可达症状。

公开证据不支持具体用户数量、损失金额，或“所有 .za 名称表现相同”的说法。它支持更窄的结论：注册局 DNS 层成为可见的连续性依赖。

注册局的证据义务

第一是精确服务边界：受影响的区域、标签、名称服务器组或商业二级域名。把事件笼统写成“.za 全部宕机”会抹掉真实控制面。

第二是时间线，分别标出首次用户症状、内部告警、自动安全动作、人工缓解、解析器可见恢复和最终稳定。ZARC 提供事件窗口和改进类别 [1]，但没有公布每个内部时间点；不能用推测填补。

第三是遥测分类。“异常流量”可能是查询激增、异常查询结构、重试风暴、机器人流量，或防御阈值与合法负载的冲突。ZADNA 支持这一概括 [2][3]，不支持最终 DDoS 标签或逐条规则诊断。

第四是解析器视角。ZADNA 对 Google Public DNS 的提及只是症状边界，不是因果归属 [2][3]。技术复盘应区分权威回答、缓存、负面响应和不同解析器的表现。

第五是把缓解与控制类别对应起来：容量、名称服务器分布、过滤、限速阈值、升级程序、监控或架构。仅说“服务已恢复”不能证明下次同类事件会更短。

接下来观察什么

未来报告应分别说明名称服务器流量、权威 DNS 行为、解析器症状和用户可达性。还应关注服务器多样性、容量余量、自动规则的安全性、遥测保留以及修复后的公开验证。

如果同一商业域服务再次中断、解析器可见故障更长、自动控制阻断合法查询，或没有范围明确的结案，风险评估应上调。若后续材料限定持续时间与影响范围、把修复绑定到具体控制，并证明架构或容量得到改善，评估可下调。

信息源

  1. https://zarc.web.za/public-incident-review-march-2025-dns-outage-and-degradation/
  2. https://www.zadna.org.za/za-namespace-experiences
  3. https://www.zadna.org.za/images/za_namespace_disruption.pdf
  4. https://www.iana.org/domains/root/db/za.html
  5. https://www.rfc-editor.org/rfc/rfc1034.txt