ttl需按业务场景动态匹配：静态网站设86400秒，cdn/负载均衡设300–3600秒，灰度发布设300秒，灾备切换设60秒；调整前查当前值、提前降ttl、改后验证全球刷新，并注意多层缓存差异与isp兼容性。

ttl（time to live）不是“设置得越小越好”或“越大越省事”，而是要根据业务变化节奏、变更频率和容错要求来动态匹配。设得太长，ip切换后用户迟迟无法访问新节点；设得太短，权威dns服务器压力陡增，解析延迟反而升高。

按业务场景选TTL值

不同服务对DNS更新的敏感度差异很大，不能一刀切：

• 静态网站、企业官网：内容极少变动，推荐 TTL = 86400（24小时），减少全球递归查询，提升缓存命中率
• CDN接入、负载均衡域名：后端节点常动态伸缩，建议 TTL = 300–3600（5分钟–1小时），兼顾生效速度与查询压力
• 灰度发布、AB测试入口：需快速切流，TTL = 300（5分钟）较稳妥；若需秒级生效，可压至 60（1分钟），但需评估上游DNS服务商是否真正遵守该值
• 灾备切换、故障转移域名：TTL = 60 是常见底线，确保1分钟内大部分用户能获取新IP；提前24小时将原TTL逐步下调更可靠

配置前的关键操作

TTL调整不是改完就生效，必须配合变更节奏执行：

IntoDNS.ai

免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。

下载

• 用 dig +ttlid example.com A 查当前生效TTL，确认起点值
• 如计划更换IP，建议提前至少一个TTL周期（例如原TTL为3600，就提前1小时）把TTL调低，再改记录
• 改完后，用 WhatsMyDNS 检查全球各节点缓存是否已刷新，避免局部未生效
• 若使用自建BIND服务器，修改 default-ttl 后需执行 sudo systemctl reload bind9；客户端systemd-resolved则需重启 systemd-resolved 服务

避开常见陷阱

很多问题其实源于对TTL机制的理解偏差：

• 本地缓存（如Windows的 ipconfig /displaydns、Chrome的 chrome://net-internals/#dns）不等于递归DNS缓存，清本机缓存≠全球生效
• TTL是“建议值”，部分老旧ISP DNS可能忽略短TTL（尤其低于300秒），实际缓存时间可能更长
• Negative cache（查无此记录的缓存）也有TTL，默认通常300秒，会影响NXDOMAIN响应的重试间隔
• DNSSEC签名记录的TTL需与对应A/AAAA记录保持一致，否则校验可能失败

多层缓存下的协同管理

一条DNS请求会经过多个缓存环节，TTL在每层独立计时：

• 浏览器缓存：Chrome等默认遵循TTL，但最多缓存1分钟（即使TTL设为1小时）
• 操作系统缓存：Windows默认最大120秒，Linux systemd-resolved 默认60秒，可通过配置覆盖
• 递归DNS（如114.114.114.114、8.8.8.8）：严格按权威返回的TTL缓存，是影响用户感知的主要环节
• 权威DNS自身：TTL在此处设定，但不参与缓存——它只决定“告诉别人能缓多久”