适用场景

为新接口 api.example.test 添加 A 记录后，监控节点已能解析，部分用户却持续报告“找不到域名”。本文以新建记录为例，区分权威服务器未同步、递归解析器负缓存和终端本地缓存。文中的 example.test、权威服务器和 IP 均为示例，执行前须替换为自己的域名与地址。

现象先分清

DNS 查询的 NXDOMAIN 表示所问的名字不存在；NOERROR 但没有 A 答案，可能是名字存在、只是没有 A 类型记录，称为 NODATA。SERVFAIL 则是解析过程失败，常见于权威链路故障或 DNSSEC 验证问题，不能当作负缓存处理。

先从故障机器查询它实际使用的递归解析器，再向另一个递归解析器查询同一个完整域名和同一种记录类型：

dig api.example.test A +noall +comments +answer +authority
dig @1.1.1.1 api.example.test A +noall +comments +answer +authority

看 status、SERVER、答案和 AUTHORITY SECTION。第一条的 SERVER 能帮助确认故障机器问到了谁；第二条只作对照，不能代替用户所用的解析器。若企业内部有私有 DNS 视图，公共解析器给出的结果本来就可能不同，不应据此认定内部 DNS 有错。

从委派走到权威服务器

先确认域名实际委派到了哪些权威服务器，不要只看 DNS 平台控制台里的配置。以下以 example.test 为示意：

dig +trace api.example.test A
dig example.test NS +short

+trace 展示从根、上级域到目标域的查询路径；如果父区委派仍指向旧服务商，需要先修正委派。dig example.test NS 经过当前递归解析器，可能受缓存影响，因此判断线上委派时以 trace 中父区返回的 NS 为准。选出实际权威服务器后，逐台查询：

dig @ns1.example.net api.example.test A +norecurse +noall +comments +answer +authority
dig @ns2.example.net api.example.test A +norecurse +noall +comments +answer +authority

把 ns1.example.net、ns2.example.net 替换为实际权威服务器。+norecurse 关闭递归请求；正常的权威应答应检查 flags 中的 aa。如果两台返回不同的 A 记录或一台仍返回 NXDOMAIN，先处理区文件发布、从库同步或 DNS 服务商节点更新。若查询被转发、没有 aa，继续找真正负责该区的权威服务器，不要把转发器当作权威证据。

权威已更新，为什么用户仍失败

在记录创建之前，有递归解析器可能已经问过 api.example.test，并缓存了权威返回的 NXDOMAIN。新记录的 A 记录 TTL 只控制已有正向答案的缓存时间，不能让此前缓存的“不存在”立即失效。

RFC 2308 规定，权威服务器在 NXDOMAIN 或 NODATA 响应的 authority 部分附带 SOA；负缓存 TTL 取 SOA 记录 TTL 与 SOA MINIMUM 字段的较小值。递归解析器返回缓存中的负响应时，SOA TTL 会随时间递减。实际保留时间还可能受解析器自身的缓存上限与策略约束。因此要看故障解析器返回的剩余 TTL，不能只读控制台中新 A 记录的 TTL。

dig @192.0.2.53 api.example.test A +noall +comments +answer +authority
dig @192.0.2.53 api.example.test A +noall +comments +answer +authority

将 192.0.2.53 换成故障用户实际使用的递归解析器。若两次均为 NXDOMAIN，authority 部分有 SOA 且其 TTL 下降，同时所有权威服务器都已返回正确 A 记录，负缓存就是很强的嫌疑。若权威也返回 NXDOMAIN，先修权威配置；若返回 SERVFAIL，排查超时、委派和 DNSSEC，不要等待负缓存 TTL。

另一个细节是：NXDOMAIN 说明名字不存在，而 NOERROR 无 A 答案只说明当前所问类型没有数据。排查时保持域名和类型一致，并检查是否有 CNAME、通配符、内部视图或终端 hosts 覆盖。采用 DNSSEC 的解析器还可能根据已验证的 NSEC/NSEC3 缓存推断不存在的名字；这时单看传统 NXDOMAIN 缓存条目可能不够。

修复与验证

  1. 权威答案不一致：检查父区委派、权威服务器配置、区序列号与同步状态；所有对外权威都返回正确答案后，再处理缓存。
  2. 权威正确、递归解析器仍返回旧 NXDOMAIN：等待负缓存过期，或在受控的自有递归解析器上按产品文档清除目标名字的缓存。公共递归解析器是否提供刷新功能及生效范围，按运营方文档确认；不要把“清空本机缓存”当作刷新公共递归缓存。
  3. 递归解析器正确、单台终端仍失败：检查操作系统或应用内 DNS 缓存、hosts、代理配置，并在同一终端复测。应用长连接和连接池也可能让“DNS 已修复”与“请求已恢复”出现时间差。

验证时重复查询同一完整域名、同一记录类型、同一递归解析器，记录 status、答案、SOA TTL 和查询时间。只有权威与受影响解析器均返回预期地址，再用实际应用请求确认恢复，才算闭环。

预防措施

  • 新服务上线前，先确认父区委派和所有权威节点可用，再开放客户端流量；把权威逐台查询纳入发布检查。
  • 若计划创建大量新子域名，提前评估 SOA 的负缓存 TTL 与发布窗口。临时降低 SOA MINIMUM 只影响之后产生的负响应，不能追溯清除已经缓存的 NXDOMAIN。
  • 故障采集保留域名、记录类型、所用解析器、查询状态、SOA TTL 和时间戳。只保存一句“DNS 不生效”，通常无法复现解析路径。

总结

处理“记录已加但有人仍查不到”时，先用权威逐台查询确认发布，再检查故障递归解析器的状态与负缓存剩余 TTL，最后排除终端缓存和应用层因素。正向记录 TTL 与负缓存 TTL 是两套时间，不应混为一谈。

参考资料