同一域名会被缓存多少遍
一次解析结果可能同时被浏览器、操作系统解析器、应用运行时与递归解析器各缓存一份，各层的过期时间互不相同。这就是为什么改完解析记录后出现「有人已经生效、有人还是旧地址」的情况。排查这类问题时，按层级从上到下一页页清或逐层验证，比反复重启应用要有效得多。
缓存层级与处置
| 层级 | 位置 | 查看与清除 |
|---|---|---|
| 浏览器 | Chrome 与 Edge 内部缓存 | chrome://net-internals/#dns 里清空主机缓存 |
| 应用运行时 | JVM、Go、Node 的连接与解析缓存 | 重启进程；Go 按记录 TTL 缓存，注意长连接复用 |
| 操作系统解析器 | systemd-resolved 缓存 | resolvectl flush-caches |
| 递归解析器 | BIND、Unbound、dnsmasq | rndc flush 或 unbound-control flush_zone |
| 权威服务器 | 无缓存，直接改 | 改完确认 SOA 序号递增，便于从属同步判断 |
快速验证是否已更新
快速验证是否已更新
dig @8.8.8.8 example.com +short # 看公共解析器的结果
dig @1.1.1.1 example.com +short # 换一个解析器对比，判断是缓存还是全网未生效
dig example.com +noall +answer # 看剩余 TTL 是否在递减
dig +trace example.com | tail -15 # 从根走到权威，确认权威已经返回新值
resolvectl flush-caches # 清本机解析器缓存后复测dig 输出读法
| 字段 | 含义 | 怎么看 |
|---|---|---|
| TTL | 该记录的剩余可缓存秒数 | 递减说明看的是缓存，恒等于配置值往往是权威直答 |
| SERVER | 应答的服务器地址 | 确认结果出自哪一层，别把递归器的回答当成权威数据 |
| flags 里的 aa | 是否权威回答 | 有 aa 说明答案来自权威，没有则来自缓存 |
| status | NOERROR 与 NXDOMAIN | NXDOMAIN 也可能被缓存，删记录后仍能看到旧结论 |
| query time | 查询耗时 | 接近零通常意味着缓存命中 |
典型使用场景
- 解析变更后的生效排查：区分是全网未生效还是局部缓存未过期
- 故障切换演练：评估切换窗口与客户端缓存的影响
- 缓存层定位：确认问题出在浏览器、系统还是递归器
- TTL 策略设计：在变更灵活性解析量与查询压力之间取舍
- 排查间歇性访问异常：确认客户端是否在反查已下线的旧地址
TTL 表示允许缓存的最长时间，不是一定会缓存这么久：公共解析器在网络异常时可能启用过期数据机制，用陈旧记录继续应答，这会让变更生效时间比预期更长。