DNS TTL 是什么？

核心解释

TTL 以秒为单位。较短 TTL 便于快速切换解析但会增加查询次数；较长 TTL 减少查询负担，却会让变更传播得更慢。

TTL 控制的是答案复用时间

DNS TTL（Time to Live）以秒为单位，告诉递归解析器和客户端一条记录可以缓存多久。缓存命中时不必再次访问权威服务器，可以缩短解析等待并降低查询压力；到期后解析器需要重新获取当前答案。

TTL 不是记录在全网复制所需的固定时间。修改解析后，不同用户看到新旧结果的差异，主要来自他们此前缓存的旧记录在不同时间到期。浏览器、操作系统和应用还可能有额外缓存行为，因此实际观察可能略有不同。

正缓存、负缓存和别名链如何叠加

• A、AAAA、MX 等成功回答按各自 TTL 缓存；同一响应中的不同记录集可以拥有不同缓存时间。
• 名称不存在的 NXDOMAIN 与无该类型记录的否定回答也会缓存，负缓存时间通常与 SOA 参数相关。
• CNAME 链中的别名和最终地址分别缓存，其中任何一层过期都可能触发部分重新查询。
• 部分解析器会设置自己的最小或最大缓存策略，权威 TTL 是重要指令，但实际客户端行为可能受到实现和网络策略影响。

故障切换与日常性能如何取舍

较短 TTL 能让计划迁移和 DNS 故障切换更快被重新查询，但会增加权威请求量，并不保证旧连接立即断开。较长 TTL 适合稳定记录，可以提升缓存利用率，却会延长错误配置和旧地址的影响时间。

实践中可按记录变化频率制定分层策略：稳定的邮件与验证记录不必追求极短 TTL，计划切换的地址可提前一个或多个旧 TTL 周期降低数值，完成并稳定后再提高。临时在切换时才降低 TTL，无法清除已经缓存的旧高 TTL。

实际应用与信息解读

TTL 数值可以直接展示，但不能简单按高低评为好坏。低 TTL 可能代表动态调度或切换需求，高 TTL 可能代表稳定配置；合理性取决于服务目标、变更方式和 DNS 托管能力。

当记录来自 CDN 或别名链时，应同时展示每层 TTL，避免只看最终地址得出错误传播时间。查询不到 TTL 或回答来自特殊缓存时，状态应为未知。

重点关注

TTL 反映的是缓存策略，不是网站速度或安全性的单独评分项；还应结合变更频率、故障切换和递归缓存行为判断。

常见问题

把 TTL 设为 0 能立即生效吗？

不能保证。旧记录可能已经按之前的 TTL 被缓存，而且部分解析器会设置自己的最小缓存时间。

TTL 越低网站速度越快吗？

通常不是。低 TTL 会让缓存更频繁失效，可能增加 DNS 查询；网站速度还取决于解析器、网络、服务器和页面资源。

修改 DNS 前多久降低 TTL？

至少应提前覆盖当前旧 TTL，并给缓存和运营流程留出余量。具体时间取决于现有 TTL 和迁移风险。