高防DNS的故障切换机制：确保99.99%可用性的技术方案

Web服务出现故障时，用户看到 502 会刷新重试；而DNS解析出现故障时，用户看到的是“域名不存在”或长时间白屏，既不重试，也往往不会报障，而是直接流失。一次解析异常的波及范围不是“一个用户”，而是“一个省份、一个运营商、一整片递归缓存下的所有用户”，并且故障会沿着递归解析链路向下游扩散，持续时间通常远长于源端故障本身：源端恢复后，下游 LocalDNS 仍会拿着过期的失败结果继续应答。因此，讨论高防DNS的故障切换，首先要建立正确的问题意识：我们要保证的并不是“服务器不宕机”，而是在任何单点、单链路、单机房、单运营商、单依赖发生故障时，客户端拿到的解析结果依然指向可用的服务。这是一个端到端的、以秒计的时间账。

一、故障切换的物理底座：三层平面

高防DNS与普通权威 DNS 的本质差异，在于它把“解析”和“防护”拆成了两套可独立失效、可独立切换的平面。缺少这一层拆分，任何切换机制都是空中楼阁。

1. 解析平面
由多组权威 DNS 集群构成，每组部署在不同可用区，对外通过 Anycast 或多 IP 发布。Anycast 的价值在于把“节点故障”和“网络故障”统一成同一个收敛动作：BGP 路由重新收敛后，流量自然被引到健康节点，无需依赖应用层感知。典型收敛时间为秒级至数十秒，明显优于依赖人工变更的切换方式。

2. 防护平面
由清洗中心（高防节点）与回源链路构成。域名解析到的并非源站真实 IP，而是高防 IP；清洗中心完成流量过滤后再回源。这带来一个额外故障域：清洗中心本身可能被打穿、可能设备故障、可能回源链路中断。因此，高防DNS的切换不只是“换一个解析 IP”，而是“换一条完整的流量路径”。

3. 调度平面
即 GSLB 或调度中心，负责持有“哪个节点健康、各节点权重多少、哪个区域走哪条线路”的实时状态表。它是整个切换机制的决策中枢，也是唯一必须做到双活甚至多活的组件：一旦调度平面自身出现单点故障，整套切换能力都会失效。

二、故障域盘点：需要被切换的六类故障

脱离故障清单谈切换机制，等于没有机制。高防DNS需要覆盖的典型故障如下：

注意最后一项：调度数据本身也会“故障”。一张错误的调度表比一次宕机更危险，因为它会让所有节点同时给出错误应答，且没有任何探针能感知“应答合法但指错了地方”。

三、五层切换机制：从感知到回切的完整链路

1. 探测层：判断 DNS 是否健康，不能只看 53 端口
这是实践中最容易做错的一环。一个权威节点端口是通的、进程是活的，但它返回 SERVFAIL、返回了被篡改的 IP、或返回的 TTL 明显异常，对用户而言就是死的。因此探测必须是语义探测而非连通性探测：

• 协议层：向目标节点发起真实 DNS 查询，校验 RCODE 为 NOERROR、应答 IP 落在预期集合内、应答段完整、TTL 处于合理区间。
• 业务层：跟随解析结果发起 HTTPS 请求，校验状态码与响应体指纹，验证“解析出来的这条路真的能通到业务”。
• 网络层：TCP SYN、ICMP 仅作为辅助信号，不能单独作为判据。

探针布点必须多地域、多运营商、分布式。单点探针的结论不可信：探针自己所在网络抖动，就会造成系统性误判。同时必须确立一条 fail-safe 原则：探测数据缺失不等于目标不可用。探针集体失联时应保持现状并告警，绝不触发全量切换。这是防止“监控系统故障引发业务故障”的最后一道保护。

主动探测之外，还需引入被动探测：用真实 DNS 查询日志与客户端上报数据计算分区域、分运营商的滑动成功率。主动探测补盲，被动探测纠偏，两者互为校验。

2. 判定层：用非对称迟滞抑制抖动
探测给出的是信号，判定才产生决策。推荐使用显式状态机：

核心设计是快降慢升的非对称迟滞（hysteresis）：连续 N 次失败即可升级为 Unhealthy（N 通常取 2–3），但恢复为 Healthy 需要连续 M 次成功并持续 T 秒，且 M > N、T 通常取 5–10 分钟。这一条能消除 90% 以上的 flapping（反复切换）。

同时引入分级判据：

• 硬故障（连接被拒、进程不存在、整机房失联）：走快速通道，一至两次采样即可判定；
• 软故障（丢包率上升、时延抖动、间歇性失败）：走慢通道，需滑动窗口内失败率超过阈值才判定。

误切本身也是一种故障。 把一个健康节点从应答池里摘掉，等于削减了整体容量；如果同时摘掉多个节点，系统会从“局部故障”变成“容量不足”。因此判定层的目标不是“最快切换”，而是“在可接受的检测时延内，把误切率压到最低”。

3. 决策层：切换要受容量约束
决策层回答三个问题：切到哪、切多少、切几级。

• 切到哪：依据加权轮询、最小负载、地域亲和、链路成本、容量水位综合排序；
• 切多少：必须做容量感知——切换后剩余容量需达到峰值负载的 1.2–1.5 倍才允许执行。否则切过去也只是把故障从“不可用”变成“过载”；
• 切几级：切换路径必须提前固化为分级降级方案，不能在故障现场临时设计。

分级降级建议四档：
1. 一级：应答池内剔除故障 IP，同集群内替换；
2. 二级：切换清洗线路或备用高防 IP，换一条完整流量路径；
3. 三级：切换备用源站集群或启用静态兜底页；
4. 四级：进入最小可用解析模式，仅保留基础 A 记录、关闭全部高级功能（智能线路、灰度、频控），用最低复杂度换最高确定性。

调度平面自身必须解决脑裂：双中心若同时决策并写入，会产出版本冲突的调度表。工程上的标准解法是“主中心持租约 + 备中心心跳接管”：备中心只有在租约超时后才允许接管，从而保证任一时刻只有一个写入者。

4. 执行层：四种 DNS 层切换手段的取舍

关键工程约束有三条：
1. 幂等：同一动作重复执行结果一致；
2. 带版本号：调度表以版本发布，所有节点按版本原子生效，杜绝“部分节点用新表、部分用旧表”造成的应答不一致；
3. 可回滚：任何切换动作保留上一版本，回滚耗时不得超过切换耗时。

5. 回切层：比切换更危险的一步
故障恢复的瞬间，所有流量同时回流，极易压垮刚恢复的节点，形成惊群。因此回切必须灰度：按 5% → 20% → 50% → 100% 分权重回灌，每级观察 5–10 分钟的错误率与时延曲线。

回切前置条件应量化为：连续成功 M 次、稳定运行 T 分钟、容量水位正常、无二次故障迹象。若回切后再次失败，自动回退，并计入“切换次数”；当 1 小时内切换次数超过阈值（如 3 次），系统应自动锁定并转入人工观察态，防止自动化把系统变成持续抖动、无法稳定的状态。

四、时延预算：一次切换到底要多久

把切换拆成时间账，才能看出真正的瓶颈在哪：

结论非常明确：切换的真实时延由 TTL 主导，而不是由探测主导。 探测做得再快，只要 TTL 是 300 秒、LocalDNS 又违规缓存更久，端到端 RTO 依然被锁死在分钟级。

因此高防DNS的可用性设计里，TTL 是第一优先级参数。推荐双 TTL 策略：稳态期使用较长 TTL（如 300s）降低解析压力；在已知敏感窗口（大促、变更、攻击预警、演练）提前 30 分钟把 TTL 降至 30s，并给下游缓存留出刷新时间，确保真正需要切换时，缓存层已经“变薄”。

五、四种“越切越坏”的反模式

• 反模式一：全网同时切换。 所有流量在同一个瞬间涌向备用路径，备用路径因瞬间过载而失效，形成二次故障。对策是按时延分批、按地域分批、并按速率上限逐步执行。
• 反模式二：探测流量自己被打。 健康检查走公网，被 DDoS 一并清除，导致探针全灭、判定失准。对策是把探针流量走带外管理通道或独立线路，并在清洗策略中显式放行探针特征。
• 反模式三：忽视下游缓存的长尾。 部分运营商 LocalDNS 不严格遵守 TTL 字段，缓存时间可达数小时。这意味着任何纯 DNS 层切换都有 RTO 下限。对策是组合使用短 TTL、HTTPDNS、以及与主流运营商建立主动刷新通道。
• 反模式四：自动化没有护栏。 全自动切换在“探测系统自身故障”场景下会做出灾难性决策——把全部节点判定为故障，然后同时摘除。必须设置三重护栏：单位时间切换次数上限、单次切换幅度上限、影响面超过阈值时强制人工确认。

六、怎么证明 99.99%：SLI、演练与可观测

可用性不能靠声称，必须靠度量。建议定义以下 SLI/SLO：

• 解析成功率（按 RCODE 分类统计）：月度 ≥ 99.99%；
• P99 解析时延：同城 ≤ 20 ms，跨省 ≤ 50 ms；
• MTTD（平均检测时延）：≤ 10 s；
• MTTR（平均恢复时延）：≤ 60 s；
• 误切率：月度 ≤ 0.5%；
• 回切成功率：≥ 99%。

验证手段依赖混沌演练矩阵：进程 kill、网卡 down、BGP 断链、清洗设备断电、调度表注入错误版本、探针集体失联（专门验证 fail-safe 是否生效）、系统时钟漂移。每一项都应有明确的预期行为和实际行为比对记录。

可观测性方面，需要建立 DNS 全链路追踪：从客户端 → LocalDNS → 权威节点 → 调度决策的每一跳都携带 trace 标识，使任何一次异常应答都能回溯到具体的判定与决策分支。配合每 1 分钟一轮、覆盖主要省份与运营商的合成拨测，才能把“用户感知之前”的故障抓出来。

七、工程落地清单

• 权威集群多可用区部署，Anycast 发布，单机房故障不影响全局；
• 探针多地域多运营商分布式布点，协议层做语义校验，不依赖端口连通；
• 探测失效时默认保持现状，不触发切换；
• 判定采用快降慢升的非对称迟滞，硬软故障分级处理；
• 切换必须受容量约束，剩余容量不足不得执行；
• 降级路径四档提前固化，故障时只做选择不做设计；
• 调度表版本化、原子生效、可回滚，双中心用租约防脑裂；
• TTL 双策略，敏感窗口提前降 TTL；
• 回切灰度分级，切换次数超限自动锁定转人工；
• 混沌演练常态化，每次演练有预期行为清单与复盘结论。

高防DNS的故障切换，本质上是一场与“不确定性”的工程博弈。真正的难点不在于把流量切走，而在于在正确的时间、以正确的幅度、切到正确的地方，并且还能安全地切回来。99.99% 从来不是靠某一个高可用组件堆出来的，它来自探测的准确性、判定的克制、决策的容量意识、执行的原子性、回切的灰度纪律，以及一整套被反复演练验证过的护栏。

相关阅读：

高防DNS的权重轮询设置：多服务器负载均衡的完整方案

高防DNS的负载均衡机制：如何实现亿级查询秒级响应

高防DNS与WAF联动防御：构建多层防护体系

高防DNS在无服务器计算(Serverless)中的应用

高防DNS的数据备份与恢复