DNS-OARC 36 会议记录了 Slack 在 2021 年 9 月 30 日尝试为 slack.com 启用 DNSSEC 导致域名解析中断 24 小时、无法回滚的事故，并讨论了 DNSSEC 部署的收益与风险。
变更管理失效的细节：
常规变更流程要求明确目标、可观测的成功指标，并准备回滚触发条件。Slack 按此准备，但在实际执行中出现了“无法回滚”的极端情况：签名变更后 slack.com 无法解析，持续 24 小时，期间无法恢复原状。事故表明，即使有完善的回滚预案，某些 DNSSEC 签名操作一旦生效即不可逆，需在部署前充分验证密钥生成、区域传播及父区 DS 记录同步。
DNSSEC 的防护效果与局限：
攻击者常通过伪造 DNS 响应或欺骗 CA 签发证书来绕过 TLS 保护。DNSSEC 可让约 30% 的互联网用户群体及大多数 CA 验证区域真实性，增加攻击成本。但 DNSSEC 并非完美：密钥管理复杂、验证链断裂会导致解析失败，且仍存在大量未验证的递归解析器。会议同时指出，自建权威服务器已不再适合全球业务，需依赖高容量、广泛分布的托管 DNS 平台。
运维建议：
在启用 DNSSEC 前，应在测试环境完整模拟密钥滚动、DS 记录提交及父区同步，确认回滚路径可行；建立实时监控解析成功率与验证失败率，设定自动告警阈值；评估托管 DNS 服务商的 DNSSEC 支持能力，避免单点故障。
对网络工程师而言，事故提醒：变更回滚能力必须在生产环境可验证，DNSSEC 能提升信任但引入新的运维风险，需在收益与复杂度之间做权衡。
原文: APNIC Blog（2021-12-07）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog