DNS 记录改了为什么还看到旧值：用 dig 连续观察缓存剩余时间

DNS 记录改了为什么还看到旧值：用 dig 连续观察缓存剩余时间教程示意图

适用日期：2026-11-02。

适用场景

调整域名记录后，一台电脑已经看到新地址，另一台仍看到旧地址，最容易想到的操作是反复清缓存。但在动手前，应该先观察究竟是哪台解析器返回了什么。本教程使用 dig 对同一解析器、同一域名和同一记录类型做三次低频查询，生成带时间的记录，从中观察缓存剩余时间。

本实验不修改域名、不清空共享缓存，也不更改系统 DNS 设置。它适合建立缓存概念，实际变更排障还需结合域名权威数据和业务连接结果。

原理

DNS 资源记录带有生存时间，通常简称 TTL，表示数据可被缓存使用的时间。递归解析器取得记录后，通常会随时间减少返回的剩余值。如果第一次观察到某条记录剩余二百秒，十秒后再次观察到约一百九十秒，并且记录内容一致，这与缓存倒计时相符。

TTL 是按记录处理的，不是整个网站统一的倒计时。一个回答中若同时存在别名记录和地址记录，各自可能具有不同的剩余时间。基础字段定义可见 RFC 1035。此外，支持过期数据应答的解析器在特定故障条件下可能继续提供旧数据，不能把 TTL 到零简单理解成所有客户端立刻换新，相关机制见 RFC 8767。

准备工作

准备能够使用 dig 的 Linux 终端。Ubuntu 或 Debian 通常通过 dnsutils 软件包提供该工具，其他发行版的软件包名称可能不同，应使用本机发行版的软件仓库安装。先确认工具可用。

dig -v

选择一个允许查询的公开域名和一台按网络管理规则允许使用的递归解析器。下面默认使用公开示例域名 example.org，仅用于查询演示，不预设它的地址或 TTL 数值。实际排障可以改为自己管理的域名，不在共享记录中写入内部名称。

分步骤操作

第一步：确认当前应答路径

先执行一次普通查询，观察完整输出。

dig example.org A

找到响应服务器（SERVER）一行，记录实际应答地址和端口。若看到本机回环地址，说明查询先到达本地代理或缓存层，不能据此认定它就是最终递归服务器。后续可以继续观察这个本地入口，也可以在网络管理规则允许的前提下，直接选择已知递归解析器。

第二步：固定查询对象

输入准备使用的解析器地址。该值必须来自实际网络配置或管理员提供的信息，不要随意选择陌生服务器。域名变量可保持演示值；更换时只填写域名，不添加网页协议前缀或路径。

read -r -p '输入允许使用的解析器地址：' resolver
name='example.org'
dig "@$resolver" "$name" A +noall +answer +comments +stats +ttlid +nottlunits

这里的解析器变量代表实际服务器地址，域名变量代表查询名称。命令保留回答、状态和服务器统计信息，并明确显示以秒计的 TTL。BIND 官方 dig 文档说明了查询服务器及输出控制选项。

第三步：保存三次低频采样

确认上一步能够收到正常回答，再执行三次采样。文件名包含当前时间，采用禁止覆盖方式创建；如名称碰巧冲突，重新执行并生成新时间即可。

report="dns-ttl-$(date -u +%Y%m%dT%H%M%SZ).txt"
(
    set -o noclobber
    for sample in 1 2 3; do
        date -u '+采样时间：%Y-%m-%dT%H:%M:%SZ'
        dig "@$resolver" "$name" A +noall +answer +comments +stats +ttlid +nottlunits
        if [ "$sample" -lt 3 ]; then
            sleep 10
        fi
    done > "$report"
)
cat -- "$report"

相邻采样之间至少等待十秒，实际间隔还包含查询耗时。三次请求足以观察基本变化，不需要改成持续高频循环。若查询出现超时或拒绝，保留错误信息并先排查解析器访问条件。

第四步：逐条比较相同记录

回答行通常依次包含名称、TTL、类别、记录类型和记录值。先确认记录名称与类型相同，再比较剩余秒数，最后比较记录值。存在多个地址时，返回顺序变化不代表地址集合发生变化，应逐项核对。

如果 TTL 近似按采样间隔减少，可以记录为“观察结果符合缓存剩余时间递减”。如果突然变大，可能是缓存更新、提前刷新，或者同一服务地址后面的不同实例接管了查询。只有三次采样时，应保留这些解释空间。

验证方法

一份可用的观察记录应包含采样时间、响应状态、实际应答服务器、名称、类型、TTL 和记录值。正常实验应取得成功响应并有可比较的回答。递归可用标志只能说明服务器提供相关能力，不能单独证明本次命中了缓存。

没有看到 TTL 下降也不代表缓存损坏。某些服务器可能调整 TTL、返回不同后端缓存的数据，或者在到期前刷新。若回答为空，应检查状态、记录类型和是否存在别名，而不是把空白当作零秒。

常见错误

只保留简短地址输出会丢掉 TTL，无法完成本实验。交替查询不同解析器，也不能把两次结果当成同一份缓存的连续变化。另一个误区是把 DNS 查询结果等同于浏览器实际连接：浏览器、应用和长连接可能各有状态，需要另外验证。

安全与回退

本教程只进行有限次数的普通 DNS 查询，不需要修改系统设置，因此无需恢复解析器配置。完成后检查报告是否含有不适合公开的名称，再决定保存范围。不要为了观察倒计时重启共享 DNS 服务或清空公司缓存。真实解析变更应提前规划 TTL，并保留旧服务的可用窗口；一次 TTL 归零不能作为关闭旧服务的唯一依据。