DNS 解析故障工作流

先区分 DNS 故障与服务故障，从多个观测点验证解析，再按 TTL 感知的方式改记录止血。

目标

当域名解析停止，条件反射是回滚服务——而服务在断裂的解析链背后健康运行时，回滚什么也修不好。从多个观测点测试解析、用 IP 直连证明服务健康，几分钟内就能把故障域从应用层剥离出来；处置时还要把 TTL 与负缓存纳入止血计划。

步骤要点

从集群内、跳板机、公共解析器、异地等多个观测点查询故障域名，先画出故障范围矩阵再谈变更。
用 curl –resolve 直连解析出的 IP 证明服务本身健康，把 DNS 层坐实为故障域。
对比权威应答与本地缓存，分辨是权威端坏了还是负缓存（SERVFAIL 按 SOA minimum 缓存）在延长故障。
在 TTL 现实内止血：改故障记录或切换备用解析商，计划里明确旧值与负缓存还会存活多久。
从原始故障观测点验证恢复，并复盘关键记录的 TTL 策略，可参与故障切换的域名改低 TTL。

排错提示

改了记录用户仍打不开多半是负缓存在起作用，把 SOA minimum 纳入恢复时间预期而不是反复改记录；把健康服务回滚了是因为没做 IP 直连验证，先分层再动手；平时 TTL 设得过长导致切换慢，就是本次事故真正的复盘动作——给可切换记录降 TTL。

适用边界

多观测点诊断依赖外部可达的解析器，封闭内网需要预设可用的对照点；TTL 调低增加查询量，权威与 CDN 成本要一并权衡。

代码示例

# scope the failure
for vp in cluster jumphost 8.8.8.8 1.1.1.1; do
  echo "== $vp =="
  dig +time=2 +tries=1 @$vp api.example.com A +short
  dig +time=2 +tries=1 @$vp api.example.com | grep -E "status|SERVER"
done
# cluster:    SERVFAIL (resolver 10.0.0.53)
# public:     203.0.113.7   (fine -> provider/local scope)

# prove the service itself is healthy
curl --resolve api.example.com:443:203.0.113.7 \
  https://api.example.com/health   # 200 OK

# authoritative vs cache
dig @ns1.example.com api.example.com +short   # 203.0.113.7
dig api.example.com @10.0.0.53 +short          # (negative-cached)