DNS容灾切换核心是记录类型+多值配置+健康探测+调度策略组合，而非仅填两个A记录；需用GTM/GSLB替代普通解析，设低TTL、双NS、地址池健康检查及多环境验证。
DNS 记录本身不直接支持“主备线路”这种逻辑，真正实现容灾切换靠的是**记录类型选择 + 多值配置 + 健康探测 + 调度策略**的组合，而不是简单填两个A记录就完事。核心思路是：让 DNS 服务能感知后端状态，并在故障时自动返回备用地址。
用全局流量管理（GTM）替代传统解析
普通A记录或CNAME无法主动探测、无法按地域/延迟/健康状态做决策。推荐使用阿里云全局流量管理（GTM）、腾讯云GSLB、或者自建PowerDNS+Health Check方案。
- 创建至少两个地址池：一个指向主机房SLB或IP，另一个指向备机房SLB或IP
- 地址池类型选“域名”更灵活（例如：main-app.example.com 和 backup-app.example.com），再单独为这两个域名配置各自的A记录指向真实后端
- 开启健康检查：GTM会定期探测每个地址池中域名的HTTP状态码、端口连通性或TCP响应，连续失败即标记为不可用
- 设置访问策略：比如“故障优先切换”——主池不可用时，100%流量切到备池；或“地域+故障”双条件，如北京用户主池故障则切上海，日本用户则切新加坡
避免常见配置陷阱
很多团队把容灾搞成“伪切换”，问题出在细节：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- TTL不能设太高：主域名的TTL建议设为300秒（5分钟），紧急割接前可临时调至60秒；否则DNS缓存未过期，用户仍会访问旧IP
- 别漏掉中间层域名的解析：如果地址池填的是域名（如 main.app.com），那这个域名本身也得有独立的、带健康检查的解析记录，否则它挂了整个链路就断了
- CNAME不能跨层级混用：比如你在GTM里配CNAME指向 kong-gateway.example.com，而这个网关又CNAME到云厂商SLB，多跳会放大解析失败风险；建议GTM直指SLB域名或IP池
- 别只依赖单家DNS服务商：确保你的域名NS服务器配置了至少2个不同厂商的权威DNS（如阿里云+Cloudflare），防止单点NS故障导致全站无法解析
简易兜底方案：多A记录 + 低TTL
若暂无GTM能力，可用基础方式过渡（仅适用于小流量或非核心业务）：
- 为同一域名添加多个A记录，分别填主、备机房的SLB或ECS公网IP
- 将TTL设为60秒以内，并确保本地DNS递归服务器支持RFC 8375（随机化返回顺序）
- 配合监控脚本：当探测到主IP异常时，自动调用DNS API删除主A记录，只保留备用记录
- 注意：这种方式无实时健康判断，依赖人工或脚本干预，且部分运营商DNS会固定返回首条A记录，存在单点风险
验证是否真生效
切完不能只看自己电脑，要从不同网络环境验证：
- 用 dig @8.8.8.8 example.com、dig @114.114.114.114 example.com 对比结果
- 用 dig +trace example.com 看解析路径是否走到GTM的权威NS
- 模拟故障：手动停掉主地址池后端服务，等待2–3个健康检查周期（如30秒×3次），再查解析结果是否已变
