TTL，即生存时间（Time To Live），是 DNS 记录中的一个数值（以秒为单位），用于告知全球解析器在向权威 DNS 服务器请求最新数据之前，应将该记录缓存多长时间。这个值直接决定了 DNS 变更在全球范围内的传播速度，因此在迁移主机或更改 IP 地址之前，它是您首先需要调整的设置之一。
DNS TTL 的工作原理（解析器缓存机制）
当用户在浏览器中输入 example.com 时，其 ISP 的 DNS 解析器会检查缓存。如果记录已被缓存且 TTL 尚未过期，解析器会立即返回缓存的 IP 地址；只有当 TTL 到期后，解析器才会向权威 DNS 服务器查询最新数据。
举例来说：若 TTL = 3600（1 小时），且解析器刚刚获取了该记录，则它将等待 1 小时后才再次查询。即使您立即更改了 IP 地址，缓存了旧记录的用户在长达 1 小时内仍会看到旧的 IP 地址。
需要理解的关键概念是：TTL 并非从您的权威 DNS 服务器开始倒计时，而是在全球每一台 DNS 解析器上独立倒计时。在实际场景中，一次 DNS 查询在到达您的权威服务器之前，会经过多个缓存层：浏览器自身的 DNS 缓存、操作系统的存根解析器，以及最重要的——由 ISP 或 1.1.1.1、8.8.8.8 等公共 DNS 提供商运营的递归解析器，这些解析器同时为数百万用户提供服务。
当 ISP 的递归解析器将您的记录存入缓存时，它便开始对自己缓存的 TTL 副本进行倒计时。假设用户 A 在 10:00 访问了您的网站，触发解析器以 3600 秒 TTL 缓存了该值。用户 B（使用同一 ISP）在 10:30 访问时，将立即从缓存获得答复而无需触及您的权威服务器，该缓存在 11:00 前持续有效。这正是 DNS 更改不会同时对所有人生效的原因：每台解析器在不同时刻开始倒计时，因此全球用户看到新 IP 的时间窗口是交错的，而非瞬间同步的。
此外，部分递归解析器会强制设置自己的最大缓存 TTL——例如，即使您设置了更高的值，也拒绝缓存超过 24 小时的内容——而另一些则会强制设置最小 TTL 以降低查询负载。因此，您设置的 TTL 最好被理解为对解析器的建议，而非它们一定会严格遵守的绝对指令。
简单规则：低 TTL = 更新更快，但 DNS 服务器负载更高 | 高 TTL = 变更传播较慢，但解析器流量更少、延迟更低
各记录类型的推荐 TTL 值
| 记录类型 | 推荐 TTL | 适用场景 |
|---|---|---|
| A Record（常规） | 3600（1 小时） | 日常正常运营 |
| A Record（迁移前） | 300（5 分钟） | 计划进行主机迁移 |
| MX Record（邮件） | 3600–86400 | 邮件记录变更频率低 |
| CNAME Record | 3600（1 小时） | 通用默认值 |
| TXT Record（SPF/DKIM） | 3600（1 小时） | 邮件安全记录 |
| NS Record | 86400（24 小时） | 极少更改 |
为每种记录选择合适的 TTL
没有一个 TTL 值能适用于所有记录，因为每种记录类型具有不同的变更频率和风险特征。基本指导原则是：对于"频繁变更或可能需要紧急更新"的记录，应使用较低的 TTL；而对于"非常稳定且极少变更"的记录，可以使用较高的 TTL，以降低负载并提升稳定性。下表总结了各场景的推荐值及其背后的实际原因。
| 场景 | 推荐 TTL | 原因 |
|---|---|---|
| A / AAAA record，日常使用 | 3600（1 小时） | 在变更速度与查询负载之间取得平衡 |
| A record，服务器迁移前 | 300（5 分钟） | 提前 24–48 小时降低，以便新 IP 快速传播 |
| MX record（邮件） | 3600–14400 | 邮件记录变更频率低，但不宜过高，以防切换服务商时延迟较长 |
| TXT（SPF / DKIM / DMARC） | 3600 | 偶尔更改；中间值便于随时调整 |
| CNAME 指向 CDN / SaaS | 3600 | 服务商可能更改目标地址；避免设置过高 |
| NS / SOA record | 86400（24 小时） | 极少更改；高 TTL 可提升稳定性 |
实际注意事项：很多人错误地将 TTL 永久保持在较低水平，理由是"以防需要随时更改"，但这会迫使解析器频繁查询您的权威 DNS，远超实际需要，不仅增加了每位用户首次加载页面的延迟，还会在 DNS 服务器出现临时故障时加大停机风险。正确的做法是"设置较高的默认值，仅在计划变更时才临时降低"，而非永久保持低 TTL。
TTL 与 DNSSEC：您需要了解的要点
DNSSEC（域名系统安全扩展）通过对 DNS 记录添加加密签名，防止缓存投毒和欺骗攻击。启用 DNSSEC 后，TTL 值变得更加关键，因为每条签名记录（RRSIG）都有自己的有效期，必须与其所覆盖记录的 TTL 相互协调。
关键规则是：DNSSEC 签名记录的 TTL 不应超过签名有效期的一半。否则，解析器可能会提供签名已过期的过时缓存记录，导致用户遇到难以诊断的 SERVFAIL 或 BOGUS 错误。大多数托管 DNS 提供商将签名有效期设置为 14–30 天，因此将主要记录的 TTL 保持在 7 天（604800 秒）以下是安全上限。
在轮换 DNSKEY 材料（构成 DNSSEC 链基础的加密密钥）时，应提前降低 DNSKEY 的 TTL，就像在服务器迁移前降低 A record TTL 一样。这样可以确保一旦发布新密钥，所有解析器能够快速获取，从而将密钥轮换期间的验证间隙降至最低。AsiaGB 支持通过平台注册的所有域名启用 DNSSEC，让您无需手动管理密钥即可开启这项保护。
| DNSSEC 记录 | 推荐 TTL | 原因 |
|---|---|---|
| DNSKEY | 3600（1 小时） | 密钥轮换期间频繁变更 |
| DS（注册商处） | 3600–86400 | 由注册商设置，可能无法直接编辑 |
| RRSIG | 与被签名记录相同 | 解析器将签名与源记录配对处理 |
| NSEC / NSEC3 | 与 SOA 最小值相同 | 否定证明；不应长时间缓存 |
TTL 与 CDN / 反向代理层
当您使用 Cloudflare、AWS CloudFront 或 Fastly 等 CDN 时，缓存情况会变得更加复杂。除了解析器层面的 DNS 缓存外，CDN 边缘节点还在全球各接入点维护着自己的缓存层。
一个常见的混淆点是：DNS TTL 与 CDN 缓存 TTL 是完全独立的两个概念。DNS TTL 告知解析器应将 CDN 边缘节点的 IP 地址缓存多长时间，而 CDN 缓存 TTL（通过 Cache-Control 响应头或 CDN 控制台配置）则告知边缘节点在向源服务器拉取新内容之前，应缓存您的内容多长时间。这两个值并行运行，必须分别规划。
最容易让管理员措手不及的场景是从一家 CDN 切换到另一家，或完全移除 CDN 直接由源服务器提供服务。正确的操作顺序是：在切换前 24–48 小时降低 DNS TTL，等待旧缓存过期，然后再将 CNAME 或 A record 更新至新目标。跳过此步骤意味着部分用户可能在数小时内仍会访问旧边缘节点，收到错误内容或报错。
# 追踪完整的 DNS 解析链，包括 CDN CNAME：
dig +trace example.com A
# 检查 CDN 响应头以确认缓存行为：
curl -I https://example.com | grep -i 'cache\|age\|x-cache'
部分 CDN 提供商（包括 Cloudflare 的"Override TTL"功能）可以强制浏览器在固定时间内缓存 DNS 答案，无论您的 DNS 记录如何设置。如果您已启用此类覆盖，请在规划任何 IP 或主机迁移前禁用它，否则该覆盖将抵消您精心调低的 DNS TTL 所带来的效果。
TTL 与电子邮件送达率
与邮件相关记录的 TTL 值——MX、SPF（TXT）、DKIM（TXT）和 DMARC（TXT）——直接影响您的外发邮件能否到达收件箱或被标记为垃圾邮件。当接收邮件服务器验证邮件是否合法时，它会查询 DNS 中发件人的 SPF、DKIM 和 DMARC 记录。如果这些记录最近刚刚更改，而接收方服务器缓存了旧版本，则身份验证检查可能会暂时失败，导致邮件被拒绝或投递到垃圾邮件文件夹。
这种情况最常发生在迁移邮件服务商时——例如从共享主机邮件切换到专用邮件服务。忽略了 TTL 处理的运维人员往往会遭遇一波退信或被标记为垃圾邮件的邮件，持续时间从一小时到一整天不等，具体取决于原始 TTL 值。
| 邮件记录 | 推荐 TTL | 备注 |
|---|---|---|
| MX Record | 3600–14400 | 切换邮件服务商前 24 小时降低 |
| SPF（TXT） | 3600 | 多个 include 指令会增加 DNS 查询次数 |
| DKIM（TXT） | 3600–86400 | 轮换 DKIM 密钥前降低 TTL |
| DMARC（TXT） | 3600 | 将策略从隔离收紧为拒绝时降低 TTL |
| BIMI（TXT） | 3600 | Gmail 中显示品牌徽标需先设置强制性 DMARC 策略 |
切换邮件服务商时最稳妥的做法是：至少在切换前 48 小时降低 MX、SPF 和 DKIM 记录的 TTL。在 DNS 中完整配置新服务商（包括其 DKIM 密钥），然后切换 MX 记录，等待传播完成，并在删除旧配置前验证收发功能正常。按照这一顺序操作，几乎可以完全避免切换窗口期内的邮件丢失。
如何在服务器 / DNS 迁移前降低 TTL
在任何主机迁移前提前降低 TTL 是一项关键的最佳实践，能确保您更改 IP 地址后，更新尽快传播至所有用户。
- 提前 24–48 小时降低 TTL：进入 DNS 管理界面，将 A Record 的 TTL 降低至 300（5 分钟）
- 等待旧 TTL 到期：若之前的 TTL 为 3600，请等待 1 小时，让所有解析器获取到新的低 TTL 值
- 执行主机迁移：在 DNS 记录中更改 IP 地址
- 检查传播情况：使用
dnschecker.org验证新 IP 是否已在全球范围内生效 - 恢复 TTL：确认迁移稳定后，将 TTL 调回 3600 或 86400
如何查看域名的当前 TTL
使用命令行
dig example.com A
# Windows（命令提示符）
nslookup -type=A example.com
在 dig 输出结果中，域名与记录类型之间的数字即为剩余 TTL。例如：example.com. 3600 IN A 1.2.3.4——"3600"即为以秒为单位的 TTL 值。
在线工具
- dnschecker.org — 同时从多个国家的 DNS 服务器检查 TTL
- mxtoolbox.com/DNSLookup.aspx — 查看所有 DNS 记录及其 TTL 值
- whatsmydns.net — 实时监控全球 DNS 传播状态
应避免的 TTL 值
- TTL = 0：部分解析器将其解释为"不缓存"，但行为因解析器而异，有些甚至可能完全拒绝该记录
- 永久低 TTL（60–300）：迫使解析器持续查询您的权威服务器，增加负载和延迟
- 极高 TTL（超过 86400）：紧急 IP 变更将需要很长时间才能完成传播
黄金法则：稳定记录的默认 TTL 设为 86400（24 小时）。仅在计划 DNS 变更前 24–48 小时内将其临时降至 300，变更完成后立即恢复。