DNS 切换与 TTL 管理
通过修改域名解析记录把流量指向备用站点。关键在于 TTL：它决定旧地址在各层缓存中还能存活多久，因此切换前必须提前把 TTL 调低并等它全网生效，否则旧解析可能持续数小时甚至数天。DNS 切换适合站点级引流，但生效时间无法精确控制，对切换时间敏感的场景通常叠加 VIP 或网关层手段。
基本信息
| 核心概念 | TTL 决定记录在递归解析器与客户端缓存中的存活时间 |
|---|---|
| 操作顺序 | 提前降低 TTL → 等生效 → 再改记录 |
| 验证方式 | 本机 dig 与公共解析器分别查询，确认收敛 |
| 限制 | 生效时间受各级缓存影响，无法精确承诺 |
典型使用场景
- 备用站点引流：主站点整体不可用时把域名指向备站点
- 机房迁移：按计划把解析逐步切到新机房
- 灰度引流：按权重把部分流量导入新集群
- 多线路容灾：配合智能解析按地域或运营商返回不同地址
- 证书或域名变更：与回切配合完成入口地址的过渡
切换操作与验证
切换操作与验证
# 0) 提前若干小时把 TTL 调到 60 秒，并确认全网已按新 TTL 缓存
dig +noall +answer app.example.com # 查看当前返回的记录与 TTL
# 1) 修改记录，指向备用站点
dig @8.8.8.8 +short app.example.com # 公共解析器视角
dig @114.114.114.114 +short app.example.com # 国内解析器视角
dig @ns1.example.com +short app.example.com # 权威服务器视角，确认已更新
# 2) 观察收敛：不同解析器逐渐返回新地址
# 3) 业务验证通过后再恢复 TTL 到原值排查要点
| 现象 | 原因 | 处理 |
|---|---|---|
| 部分用户仍访问旧地址 | 本地或递归缓存未过期 | 降低 TTL 并等待，必要时联系解析服务商刷新 |
| 切换后解析异常 | 记录值或记录类型写错 | 核对 A/AAAA/CNAME 与泛解析规则 |
| 验证结果不一致 | 不同解析器缓存时间不同 | 多解析器交叉验证，取最慢的作为窗口预期 |
| TTL 未生效 | 修改前记录 TTL 过长 | 记录变更时间，按原 TTL 估算过渡期 |
DNS 切换的关键动作都在『切换之前』：提前降 TTL、提前把备用站点的证书、白名单与依赖打通，切换窗口内只剩改记录与验证两件事。