DNS 健康检查判定对照表
你是 DNS 故障转移健康判定助手。只根据用户配置对照文档逻辑，不要编造已切换解析。
健康检查配置：{{hc_config}}
记录/故障转移策略：{{dns_policy}}
现象：{{symptom}}
输出 Markdown：
1. 检查类型归类（端点/计算/告警流）与判定要点
2. 可能误判（证书不校验、字符串匹配、数据不足默认健康、跨账号告警）
3. 切流前核对清单
4. 值班群一句话
禁止声称已改 TTL 或权重；禁止索要云账号。场景说明
面向独立开发者与 SRE：把 Route53/类 DNS 健康检查「为何判不健康」写成可对账清单，区别于负载均衡目标组健康检查。
案例叙事
01他们做了什么
站点「半个地球打不开」时，值班常先查 LB，却忘了 DNS 故障转移本身用的是另一套全球探测与聚合规则。
Amazon Route 53 文档说明：判定健康检查是否健康取决于类型。监控端点时，全球多地健康检查器按你选择的地点与间隔（10 或 30 秒）发请求；各地不互相协调，因此可能出现短时密集请求后短暂空窗。个体检查器看响应时延与连续失败阈值；Route 53 汇总后：超过约 18% 的检查器报健康则整体视为健康，≤18% 则不健康——该阈值旨在避免因部分网络隔离误判。HTTP/HTTPS 需在约 4 秒内建连且 2 秒内返回 2xx/3xx；TCP 需约 10 秒内建连；带字符串匹配时还须在随后窗口内于响应体前 5120 字节找到指定串。HTTPS 检查不校验证书是否过期/无效。另有监控其他健康检查的计算型，以及基于 CloudWatch 告警数据流（非告警状态本身）的检查；不支持跨账号告警。新检查在数据不足前默认视为健康（若反转状态则相反）。本场景据此输出判定表。禁止声称「已自动完成 DNS 切换」。
02实际效果
- 源未披露量化「故障转移平均切换耗时」；公开文只描述探测聚合阈值、协议时限与检查类型差异。
- 能把「DNS 判不健康」与「LB 目标全红」分开排查。
- 切流前有对照清单，减少因证书/字符串匹配配置误杀。
03值得知道
- 各 DNS/GSLB 产品的健康判定阈值不同；本页作 Route 53 机制参考。
- 18% 等阈值可能随产品演进调整，以当前文档为准。
- 上面写的是文档能力说明，不是你的解析实时状态。
04可复制提示词
误切流/未切流复盘提纲
DNS 故障转移行为与预期不符，请写复盘提纲。
预期：{{expected}}
实际：{{actual}}
时间线：{{timeline}}
输出：
1. 可能根因分层（探测、聚合、记录策略、缓存 TTL）
2. 证据要看什么
3. 临时缓解
4. 防再发
不要伪造「全球已一致」。怎么做
- 粘贴健康检查类型、间隔、失败阈值、探测路径与当前 DNS 记录策略
- Agent 按端点/计算/告警流三类输出：判定逻辑对照、常见误判、切流前核对项
- 人工在 DNS/健康检查控制台验证；Agent 不代改记录权重
实用提示
- DNS 健康检查与 LB 目标健康是两层：边缘探测聚合阈值不同于目标组连续失败计数
- 与 alb-target-health-check-fail-triage 不同：本条是 DNS 故障转移侧如何判定 healthy/unhealthy