DNS TTL优化需按业务场景动态匹配：静态网站设86400秒，CDN/负载均衡设300–3600秒，灰度发布设300秒，灾备切换设60秒；调整前查当前值、提前降TTL、改后验证全球刷新，并注意多层缓存差异与ISP兼容性。
优化 DNS 解析的 TTL 时间，核心是让缓存时长匹配业务变化节奏——既不能太长导致切换慢，也不能太短拖垮权威服务器或引发解析延迟。
按业务场景选对 TTL 值
不同服务对更新敏感度差异大，不能统一设 3600 或 86400：
- 静态官网、文档站、企业门户：内容极少变动，TTL 设为 86400（24 小时），大幅降低全球递归查询压力，提升缓存命中率
- CDN 接入、四层负载域名：后端节点常伸缩，TTL 推荐 300–3600（5 分钟–1 小时），兼顾生效速度与稳定性
- 灰度发布、AB 测试入口：需快速切流，TTL 设为 300（5 分钟） 较稳妥；紧急时可压至 60（1 分钟），但要实测主流 ISP 是否遵守
- 灾备切换主域名：TTL 必须设为 60，并提前 24 小时完成逐步下调，确保故障发生后 1 分钟内多数用户能回切
变更前必须提前降 TTL
TTL 修改本身需要时间传播，不能等要切 IP 才改——旧 TTL 还在缓存中，新设置根本来不及生效：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 若原 TTL 是 86400，至少提前 24–48 小时开始操作：先调至 3600，12 小时后再调至 300
- 用 dig example.com A +ttlid 查当前权威返回的 TTL，再用 dig @8.8.8.8 example.com A 确认公共 DNS 是否已同步新值
- 若变更紧急且原 TTL 极大，可同步启用 HTTP 层重定向或负载均衡器临时接管流量，避免用户访问中断
改完后逐层验证真实缓存状态
后台显示“已保存”不等于用户看到新 IP。DNS 是多层缓存体系，每层独立计时：
- 用 WhatsMyDNS.net 查全球主要节点（重点关注北京、上海、深圳等用户集中地）是否返回新 IP
- 本地排查三类缓存：浏览器（Chrome 访问 chrome://net-internals/#dns）、系统（Windows 运行 ipconfig /displaydns）、运营商递归 DNS（如 nslookup example.com 114.114.114.114）
- 注意 Negative Cache：查过不存在的子域名（NXDOMAIN）也会被缓存，默认 300 秒，可能掩盖真实问题
避开常见执行陷阱
很多“更新不生效”其实卡在细节上，而非 TTL 设置本身：
- 浏览器强制缓存上限：Chrome 最多只缓存 60 秒，即使 TTL 设为 3600，二次访问也可能走新解析——测试易失真
- 操作系统限制：Windows 默认最大缓存 120 秒，Linux systemd-resolved 默认 60 秒，实际受本地策略压制
- 老旧 ISP DNS 可能忽略短 TTL：尤其低于 300 秒时，部分中小运营商仍按自身策略缓存 10–30 分钟，需多地实测确认
- DNSSEC 签名记录的 TTL 必须与 A/AAAA 记录严格一致，否则校验失败会导致解析被拒
