题干与适用场景
这道通用技术题考察网络基础和排障方法。重点是区分“权威记录已经改变”和“递归解析器或客户端仍在缓存旧答案”，避免把 DNS 当成瞬时全网广播。
面试官考察什么
- 能否说清 stub resolver、递归解析器和权威服务器的职责。
- 能否正确解释 TTL、负缓存和不同记录类型的独立缓存。
- 能否用多地点、多解析器查询定位缓存层或委派问题。
- 能否设计可回滚的 DNS 切换计划，而非只执行清缓存。
回答前需要澄清的问题
先确认修改的是 A、AAAA、CNAME 还是委派 NS；新旧地址是否都健康；问题是所有用户还是特定运营商、地区或网络；变更前 TTL、SOA 的负缓存参数和 DNSSEC 状态是什么；应用是否还固定解析结果或使用连接池。
30 秒回答框架
我会先直接查询权威服务器确认新记录，再从多个公共递归解析器和受影响网络查询并比较 TTL。若权威已更新，旧答案通常来自缓存或更长的上游 TTL；若权威没更新，则检查委派、区域发布和自动化。切换前降低 TTL 并提前等待旧 TTL 到期，切换时保留双活，验证后再下线旧地址。
分步骤深入解答
1. 画出实际查询链路
应用通常先经过浏览器或系统的 stub resolver，再询问递归解析器；递归解析器在缓存未过期时直接返回，否则沿根、顶级域和权威服务器查询。权威服务器保存区域的事实记录。每层可能有自己的缓存与刷新时间，因此用户看到的答案不一定等于权威答案。
2. 用 TTL 和负缓存解释时间
TTL 越长，缓存命中越多、查询压力越低，但变更生效更慢。记录更新后，已经缓存的旧答案通常要等其 TTL 归零；负面响应也可能按 SOA 相关参数缓存，导致刚创建的记录仍返回不存在。不同记录类型和不同解析器的剩余 TTL 要分别观察，不能承诺一个固定传播秒数。
3. 设计可重复的排查命令
先向权威服务器查询，确认区域和委派一致；再从多个递归解析器、地区和网络查询同一名称、类型与 flags，记录答案、TTL、响应码和时间。对比“权威正确、递归旧”“权威不一致”“只有客户端旧”三种模式，分别指向缓存、区域发布或本地缓存。
4. 排除 DNS 之外的旧地址
即使 DNS 已更新，HTTP 代理、CDN、应用配置、连接池、服务发现或本地 hosts 文件也可能继续使用旧地址。检查请求实际命中的 IP、TLS 证书、响应头和负载均衡日志，确认问题确实发生在解析阶段，而不是路由或应用缓存。
5. 规划安全切换
在切换前把 TTL 降到业务允许的较低值，并提前等待原 TTL 窗口结束；新旧端点同时可用。切换后按地区和解析器持续监控答案分布、错误率和真实流量，保留旧端点直到风险窗口结束。若发现问题，恢复旧记录仍需等待缓存，因此要提前准备应用层降级或双活。
高质量示范回答
我会先确认权威服务器上的记录和委派是否一致，再从多个递归解析器和受影响网络查询同一名称，记录答案与剩余 TTL。权威已更新而递归仍返回旧地址，说明缓存尚未过期；权威不一致则检查区域发布、NS 或自动化；只有少数设备异常时再查系统缓存、hosts、代理和连接池。TTL 决定旧答案还能被使用多久，负缓存还会影响刚创建的记录，所以我不会承诺一个固定传播时间。正式切换前降低 TTL 并等待窗口，保持新旧端点双活，切换后观察真实流量与错误率，直到确认可以下线旧地址。
常见错误
- 说 DNS 传播“几分钟必然完成”，忽略既有 TTL。
- 只在自己的电脑上清缓存，不能证明递归解析器状态。
- 只查一个公共 DNS，无法发现地区或委派差异。
- 修改 A 记录却忘记 AAAA、CNAME、NS 或 DNSSEC。
- 权威记录已更新就立刻关闭旧服务，没有双活和回滚窗口。
- 把 CDN、代理或 hosts 文件造成的旧地址误判成 DNS 问题。
追问及应对
为什么新建记录仍然返回 NXDOMAIN？
上游可能缓存了负响应，按 SOA 相关负缓存参数保留。先确认权威记录确实存在，再等待负缓存到期；不要只反复刷新客户端。
TTL 已经调低，为什么旧答案还在？
降低 TTL 只影响之后获取的缓存，已经存在的缓存仍按旧 TTL 倒计时。还要检查是否改到了正确的记录、区域或权威服务器。
能否强制所有用户刷新 DNS？
无法控制所有递归解析器和客户端。应通过提前降 TTL、双活、应用层路由和监控降低切换风险。
如何判断是 IPv6 导致的旧服务？
分别查询和测试 A、AAAA，记录客户端实际连接的地址族。若 AAAA 仍指向旧端点，单独修复它，不要只验证 IPv4。