summary
2025-10-19 23:48 PDT 起，us-east-1 的 Amazon DynamoDB 出现 API 错误率升高。根因是 DynamoDB 自动化 DNS 管理系统中的一个潜在竞态条件：DNS Planner 生成区域 DNS 计划，DNS Enactor 在三个 AZ 独立冗余地执行。一次异常的 Enactor 延迟，使第二个 Enactor 先应用了更新的计划并清理了旧计划；被延迟的 Enactor 随后用其陈旧（更旧）的计划覆盖了区域端点，而清理流程又把这个旧计划删除，导致 dynamodb.us-east-1.amazonaws.com 出现不正确的空 DNS 记录，且自动化无法自我修复，需人工干预。由于大量 AWS 核心服务依赖内部 DNS 解析，DynamoDB 端点解析失败迅速级联到 EC2/Lambda/NLB/STS/控制台登录等。
timeline
10-19 23:48 PDT DynamoDB API 错误率升高；依赖 DynamoDB 的内部/外部流量 DNS 解析失败。10-20 00:38 工程团队定位到 DynamoDB DNS 状态为根因；01:15 临时缓解恢复部分内部连接；02:25 全部 DNS 信息恢复，02:40 客户侧缓存过期后恢复主要服务。但 EC2 新实例启动因 DWFM 进入拥塞崩溃状态，直至 13:50 PDT 才完全恢复；NLB 健康检查问题持续至 14:09；全局服务约 14:20 PDT 全部恢复。
root_cause
DynamoDB 自动化 DNS 管理存在竞态：冗余 Enactor 间计划版本不一致，陈旧计划覆盖并随后被删除，产生空 DNS 记录且系统无法自愈；而 AWS 大量核心服务强依赖该内部 DNS，单点 DNS 失效即引发大面积级联。
amplifiers
① 内部 DNS 强耦合：众多核心服务依赖同一 DynamoDB 区域端点 DNS，单点失效爆炸半径极大。② 竞态不可自愈：空记录产生后自动化无法修复，需人工。③ 恢复长尾：EC2 启动依赖的租约/网络子系统在 DNS 恢复后仍拥塞数小时。④ 跨服务连锁：NLB/STS/控制台登录均被拖入。
mitigation
应用临时缓解恢复内部连接；人工修正 DNS 计划并重建记录；对 EC2 的 DWFM 做节流与选择性重启以解除拥塞崩溃；NLB 通过禁用自动健康检查故障转移缓解。后续强化 Enactor 计划版本一致性与冲突检测。
lessons
内部核心 DNS 需消除单点并具备自愈；多副本执行器必须就计划版本做强一致与冲突检测；关键服务对依赖 DNS 失效应 fail-open/降级而非全断；恢复流程要避免长尾拥塞。
checklist
① DNS Enactor 增加计划版本一致与冲突检测。② 核心 DNS 记录增加自愈与防护。③ 关键服务对依赖 DNS 失效做降级而非全断。④ EC2/DWFM 增加拥塞崩溃防护与快速重启。