如何配置自动 DNS 解析切换
自动解析切换解决了一个常见问题。你可以通过基于 DNS 的故障转移和健康检查来配置自动 DNS 解析切换。这种方法能够减少停机时间和人工干预，同时增强服务器集群的高可用性。
你将学习如何完成前置准备、选择自建或云端方案、定义健康检查探针，然后控制记录更新。你还将测试故障转移行为，并验证在网络事件发生后，流量是否会到达正确的服务器。每一步都建立在前一步之上，因此你可以从准备到验证，掌握一套完整的工作流程。本指南将提供实现这一目标的实操步骤。
DNS 故障转移的前置条件
准备服务器和 DNS 访问权限
你需要一个已注册域名，并由支持自动健康检查和 API 驱动更新的服务商进行管理。建议至少规划两台位于不同区域或数据中心的服务器。一台作为主服务器，另一台在主服务器出现问题时接管服务。你还需要访问服务商的管理控制台或 API，并对 A 记录、CNAME 记录以及 TTL 值有基本了解。
在故障转移生效之前，你可能需要修改某个 DNS 服务器条目，或核验现有记录。请检查你的路由器管理界面，例如 192.168.1.1，并查看 Windows 11、macOS 和 Linux 上操作系统级别的 DNS 设置。在 Windows 11 中，Dnscache\Parameters 注册表项下的四个 DWORD 值可以收紧故障转移行为：
| 注册表值（DWORD） | 数值 | 用途 |
|---|---|---|
| MaxCacheTtl | 1 | 将 DNS 缓存 TTL 设置为 1 秒 |
| MaxNegativeCacheTtl | 0 | 阻止缓存无效条目 |
| ServerPriorityTimeLimit | 0 | 启用回退到辅助 DNS 服务器 |
| ServiceDllUnloadOnStop | 1 | 在停止时卸载 DNS Client 服务 |
重启后这些更改才会生效。之后，当主 DNS 服务器停止响应时，辅助 DNS 服务器几乎可以立即接管。
定义健康检查端点
一个可靠的健康检查端点应验证真实的应用健康状况，而不仅仅是返回一个 200 状态码。它应确认数据库连接、缓存可用性以及关键依赖项是否正常。对于 HTTP 检查，请请求诸如 /health 的特定路径，期望返回 2xx 或 3xx 状态码，并将超时时间设置为 5–10 秒。对于 HTTPS，请验证 TLS 握手，并可选择强制校验证书有效性。对于 TCP，请确认端口能在超时时间内接受连接。
使用多个健康检查位置可以避免因网络问题导致误判。请在故障转移触发前就监控状态并对故障发出告警。定期测试故障转移，例如每季度进行一次演练，并记录人工处置流程。如果你计划稍后更改 DNS 服务器设置，请保持这些记录为最新，以确保你的自定义 DNS 服务器和 DNS 服务器地址在整个网络中始终准确。
如何配置自动 DNS 解析切换
自建 DNS 方案
当你在自己的硬件上配置自动 DNS 解析切换时，BIND 可以提供完全控制。首先使用 rndc-confgen -a -b 512 -r /dev/urandom 生成 rndc 身份验证密钥，该命令会将密钥写入 /etc/rndc.key。通过将该文件的所有者设置为 root:named、权限设置为 0640 来加固它。在主配置文件 named.conf 中，包含 rndc 密钥文件，并定义一个 controls 块，允许在 127.0.0.1 的 953 端口上使用 rndc-key 进行 rndc 管理。定义主区域时，使用 allow-update { key rndc-key; }; 和 notify yes;，以便动态更新通过身份验证。在从服务器上，接受来自主服务器的区域传送，并使用相同的密钥允许更新。编辑动态区域文件前，先执行 rndc freeze <zone>，然后执行 rndc reload <zone> 和 rndc thaw <zone> 以重新启用更新。使用 nsupdate -k /etc/rndc.key 可以在无需重启的情况下进行在线修改，并通过 named-checkconf、named-checkzone 和 rndc status 验证一切是否正常。
“Hi Tarwan，也许 failover 不是描述它的最佳词汇。用 master-slave replication 可能更贴切。你仍然能从更高的可用性中获益，因为如果你的 master 宕机，slave 拥有所有记录，并且可以继续提供服务。”
对于更轻量的部署，dnsmasq 配合健康检查脚本也很适合。你的脚本会探测主服务器，然后在探测失败时重写 dnsmasq 的 hosts 条目并发送 SIGHUP 信号。这样可以让切换过程保持本地化且足够迅速。
云端 DNS 故障转移路由
AWS Route 53 以不同方式处理故障转移。它不会重写已存储的记录，而是在查询时做出路由决策。你可以为每个资源创建健康检查，或者对别名记录将 Evaluate Target Health 设置为 Yes。然后创建主记录和备用记录，它们需要具有相同的名称、类型和路由策略，并分别绑定到各自的健康检查。将 Routing Policy 设置为 Failover，并指定 Primary 和 Secondary 记录类型。当健康检查报告主资源不健康时，Route 53 会使用健康的备用记录来响应查询。你可以通过 CloudWatch 指标（如 HealthCheckStatus 和 HealthCheckPercentageHealthy）以及告警、Lambda 检查和 EventBridge 规则来监控这一过程。
Azure 将这项工作拆分开来。Azure DNS 本身不提供健康检查，因此你需要再配合 Traffic Manager 作为第二项服务来实现故障转移路由。
| 对比项 | AWS Route 53 | Azure Traffic Manager |
|---|---|---|
| 服务模型 | 统一的 DNS、健康检查与路由 | 独立的路由服务 |
| 故障转移路由 | 内置故障转移策略 | 优先级路由方式 |
| DNS 托管 | Route 53 是权威 DNS | 需要 Azure DNS |
如果你在客户端更改某个 DNS 服务器条目或更改 DNS 服务器设置，解析优先级还取决于接口度量值以及 DNS 服务器顺序。在生产环境中更改 DNS 服务器之前，请先规划好这些因素，并记录整个网络中每一项与更改 DNS 服务器相关的变更。
健康检查与切换逻辑
选择 DNS 健康检查探针
你选择的探针类型决定了健康检查实际能发现什么问题。Ping（ICMP）可以确认主机的基本可达性，但防火墙经常会阻止它，而且它无法证明应用本身正常运行。端口（TCP）检查可以确认某个服务端口是否接受连接，但它无法判断应用逻辑是否正常。HTTP(S) 探针会请求诸如 /health 的路径，并期望得到 2xx 或 3xx 状态码，因此它是 Web 服务最有力的健康信号。将 ICMP 与 TCP 或 HTTP(S) 结合使用，你就能同时捕捉网络层和服务层的故障。
| 探针类型 | 典型使用场景 | 局限性 | 推荐搭配 |
|---|---|---|---|
| Ping（ICMP） | 验证主机的网络可达性 | 可能被防火墙或 ICMP 过滤阻止；无法确认应用可用性 | 与 HTTP(S) 或端口（TCP）搭配，以检测服务层故障 |
| 端口（TCP） | 检查指定服务端口是否开放并接受连接 | 无法验证应用逻辑或内容层错误 | 结合 Ping（用于网络层）或 HTTP(S)（用于应用层） |
| HTTP(S) | 检查网站、API 或 Web 应用的可用性与响应状态码 | 无法检测 DNS 问题、网络层故障或 SSL 证书过期 | 与 DNS（用于解析）及 SSL/TLS（用于证书健康）搭配 |
时间参数决定了检测速度。请根据你期望的恢复时间来配置健康检查间隔，以及触发故障转移前所需的连续失败次数。常见做法是设置一个在快速检测与减少误报之间取得平衡的失败阈值。
探针会通过 HTTP、HTTPS、TCP 或 ICMP，以可配置的间隔测试每个端点，并可提供更快的检查间隔。检查会同时从多个区域发起，因此单一路径上的网络抖动不会触发误切换。
重试机制还增加了一层保障。你可以配置多少次连续失败后将设备标记为宕机，以及多少次连续成功后将其恢复上线。这些参数将决定故障转移和恢复所需的时间。
自动化记录更新与 TTL
自动化会用 API 调用取代人工在控制台中的修改，因此每一次变更都能同步到所有平台。请使用 DNS 服务商提供的 API（REST、Terraform 或 SDK）来自动修改记录，并应用基于角色的访问控制，同时保留审计日志。在各个权威副本之间复制区域内容，以确保在故障转移发生前，备用应答已经准备就绪。
TTL 决定了解析器会信任一个应答多久。更低的 TTL 有助于更快的故障转移。在计划中的变更之前，应提前足够时间降低 TTL，以便旧的缓存应答过期。某些解析器会强制执行 30 秒的最小下限，因此低于这个值并不能被稳定地遵守。
接口度量值和 DNS 服务器顺序也会决定解析优先级。当你配置自动 DNS 解析切换时，请在投入生产前规划好这些因素。一个配置了两个 DNS 条目的客户端会优先查询列表中的第一个服务器，而在多宿主主机上，接口度量值会用于打破优先级平局。请记录每一项更改 DNS 服务器所需的变更，并在整个网络中保持连接记录的最新状态。
测试并验证故障转移
模拟故障并查看日志
如果你从未真正触发过故障转移，就不能真正信任这套方案。停止主服务、阻断其健康检查端口，或者拔掉它的网络链路。观察 DNS 记录需要多长时间切换到备用服务器。然后检查服务商日志或 BIND 查询日志，确认切换发生的准确时间点。
接下来查看健康检查历史。关注失败次数、时间戳以及恢复事件。干净的日志应只显示一次清晰的状态转换；而混乱的日志则表明出现了抖动，这意味着你的阈值设置过于敏感。请按计划重复演练，并记录每个步骤耗费了多长时间。
验证更改 DNS 服务器设置
客户端行为决定了故障转移是否真的能帮助用户。在 Windows 11 上，手动指定一个 DNS 条目，并确认解析器确实使用了新的 DNS 服务器地址。在 macOS 上，可以通过终端中的 networksetup 命令设置 DNS 服务器并验证更改。
你还可以在 Cisco 交换机上更改 DNS 服务器，并将记录映射到正确的主机。每次更改后，都应清空缓存并再次查询该名称。确认返回结果指向健康服务器，同时检查那些仍由 DHCP 管理的客户端是否依旧自动获取 DNS 服务器地址。在宣布测试完成前，请从多个网络路径验证连通性。
现在你已经掌握了完整流程：准备服务器和 DNS 访问权限，选择自建或云端方案，定义健康检查探针，调整切换逻辑，然后验证结果。自动化能够让你的 DNS 应答保持准确，并加快事故响应速度。
请通过以下习惯来维护这套配置：
- 每次故障后复查健康检查阈值。
- 关注 TTL 对传播速度的影响。
- 保护 DNS 凭证和 API 密钥安全。
- 在基础设施变更后重新测试故障转移。
在你的解析器配置中添加多个解析器，并使用虚拟 IP 故障转移工具在健康检查脚本失败时迁移虚拟 IP。监控 DNS 解析器状态。务必先在预发布环境中配置自动 DNS 解析切换，再部署到生产环境，这样你的服务器和网络才能保持韧性。
常见问题
自动故障转移究竟多快可以切换流量？
检测时间取决于你的探针设置，例如健康检查间隔以及触发故障转移所需的连续失败次数。降低检查间隔和失败阈值可以更快检测到问题，但也要防范因单个丢包造成误报。
不使用云服务商也能运行故障转移吗？
可以。你可以在自有硬件上使用 BIND 配合 rndc，或使用健康检查脚本。脚本会探测主服务器，在探测失败时重写 hosts 条目并发送 SIGHUP 信号。这能让切换保持本地化且足够迅速。
为什么故障转移后客户端仍然访问已宕机的服务器？
很可能是解析器缓存了旧应答。请检查该记录的 TTL。标准 A 记录可能有默认 TTL，这会让缓存数据在切换后仍保留很长时间。清空缓存后重新查询该名称，以确认结果是否已经更新。
在计划切换前，我应该将 TTL 设置为多少？
应在计划变更前足够早地降低 TTL，以便旧的缓存应答能够过期。某些解析器会强制执行 30 秒的最小下限，因此低于这个值并不能被稳定采纳。
两台服务器都需要健康检查吗？
需要。只检查主服务器并不能确认备用服务器是否真正可用。请同时探测两个端点，使用多个检查位置，并在故障转移触发前对异常发出告警。每季度测试一次完整链路，这样你才能真正信任结果。
