TTL 与缓存时间
TTL（Time To Live）是 DNS 记录的存活秒数，规定递归解析器与客户端最多能把这条记录缓存多久，到期后必须回权威重新查询。它同时决定两件事：改动多久全网生效，以及权威服务器要承受多少查询量——这是运维里最常被反复权衡的一个数字。
基本信息
| 取值范围 | 0–2147483647 秒；0 表示不缓存 |
|---|---|
| 语义 | 「最多缓存这么久」，不是「一定缓存这么久」 |
| 负缓存 | NXDOMAIN/NODATA 的缓存时长取 SOA MINIMUM 与 SOA 自身 TTL 的较小值 |
| 规范 | RFC 2181 §8、RFC 2308 |
| 运维实践 | 变更前提前降低，稳定后适度放宽 |
各级缓存的 TTL
| 层级 | TTL 从哪来 | 说明 |
|---|---|---|
| 权威 | 记录自带的 TTL 字段 | 是上限，每次应答都重新给出这个值 |
| 递归解析器 | 收到时保存并逐秒递减 | dig 返回的是剩余时间，不是原始 TTL |
| 操作系统 stub | systemd-resolved/nscd 有独立缓存 | 与递归器缓存是两套，要分别清 |
| 浏览器 | 独立实现，通常有固定上限 | 清 host cache 可绕过，适合验证 |
查看各级剩余时间
查看各级剩余时间
dig +noall +answer example.com A # 权威视角的原始 TTL
dig +noall +answer @8.8.8.8 example.com A # 公共递归器里的剩余 TTL，通常更小
dig +ttlunits +noall +answer example.com A # 输出成 1h / 5m 更好读
resolvectl flush-caches # 清 systemd-resolved 缓存（需 root）怎么定这个值
- 稳定不变的服务：3600 秒甚至 86400 秒，降低权威负担
- 计划中的迁移：提前 24–48 小时降到 60–300 秒，让旧记录先过期
- CDN 或灰度切换：300 秒左右，兼顾生效速度与查询量
- 故障应急回滚：配合短 TTL 才能在几分钟内切回旧地址
- 永远不要为了「立刻生效」而设 0：每次查询都打到权威，极易触发限流
解析器可以不等到期就提前回源，也可以在权威不可用时按 RFC 8767 继续用过期数据。因此「TTL 到了就一定生效」并不成立，排错要看实际返回。
变更标准动作
- 提前 24–48 小时把 TTL 降到 60–300 秒，并等到旧的长 TTL 缓存自然过期
- 在维护窗口执行变更，改完用多个公共解析器交叉验证（指定 8.8.8.8、1.1.1.1 各查一次）
- 确认新记录生效后继续保持短 TTL 一段时间，给回滚留出余地
- 运行稳定后再把 TTL 调回 3600 秒级，降低权威服务器的查询压力
- 把改动的域名、时刻、新旧值写进变更记录，避免下次排错不知道谁改过