TTL需按业务变化节奏动态匹配：静态网站设86400秒，CDN/负载均衡设300–3600秒，灰度发布设300秒，灾备切换设60秒；调整前须查当前值、提前降TTL、改后验证全球刷新，并注意多层缓存差异与ISP兼容性。
合理设置 TTL 值，核心是让缓存时长匹配业务变化节奏——既不能太短导致权威 DNS 压力大、解析延迟高，也不能太长导致变更后用户迟迟看不到新地址。
按业务场景选基础值
静态内容类（如企业官网、文档站、博客）极少改 IP，TTL 设为 86400（24 小时）即可。这样全球递归 DNS 缓存时间长，查询压力小，解析速度快。
CDN 接入、四层负载域名，后端节点常动态伸缩，TTL 推荐 300–3600（5 分钟到 1 小时），兼顾更新及时性与稳定性。
灰度发布或 AB 测试入口，需快速切流，TTL 可设为 300；若要求更灵敏，可压至 60，但要确认主流 ISP DNS 实际遵守该值。
灾备切换主域名，TTL 应设为 60，并提前 24 小时完成降级操作，确保故障发生时多数用户 1 分钟内能获取新 IP。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
变更前必须提前降 TTL
不能等要换 IP 时才调 TTL——它本身需要时间传播。例如原 TTL 是 86400，当天改成 300，大部分递归 DNS 仍按旧值缓存 24 小时。
- 计划变更前至少 24–48 小时开始操作：先将 TTL 改为 3600，12 小时后再改为 300
- 用 dig example.com A +ttlid 查当前权威返回的 TTL，再用 dig @8.8.8.8 example.com A 看公共 DNS 是否已同步新值
- 若原 TTL 极大且变更紧急，可同步启用 HTTP 重定向或负载均衡器临时接管流量
改完后验证真实缓存状态
后台显示“已保存”不等于用户已看到新记录。浏览器、操作系统、ISP 本地 DNS 各层缓存独立计时，必须分层验证：
- 用 WhatsMyDNS 检查全球主要节点是否已刷新
- 查本地缓存：Windows 运行 ipconfig /displaydns，Chrome 访问 chrome://net-internals/#dns
- Linux 用户可查 systemd-resolved 状态，必要时执行 sudo systemd-resolve --flush-caches
避开常见理解偏差
TTL 是建议值，不是强制指令。部分老旧 ISP DNS 可能忽略短 TTL（尤其低于 300 秒），实际缓存更久。
浏览器自身有缓存上限：Chrome 最多缓存 60 秒，Windows 默认最多 120 秒，Linux systemd-resolved 默认 60 秒——即使你设了 3600，用户端也不一定真缓存那么久。
Negative cache（如 NXDOMAIN 响应）也有 TTL，默认常为 300 秒，会影响错误域名重试间隔；DNSSEC 签名记录的 TTL 必须与对应 A/AAAA 记录一致，否则校验失败。
