从客户端视角逐层向上
排查解析故障最忌讳上来就改配置。合理的顺序是先确认客户端实际拿到什么，再一层层向上验证：应用的查询入口、本机解析器配置、递归器返回结果、权威服务器的回答，最后核对整条委派链路。每一层都能单独测试，因此可以很快把范围收敛到某一层，而不是在整条链路上凭感觉猜。
五步排查
五步排查
getent hosts www.example.com # 1 应用视角：与程序实际调用同一套解析入口
cat /etc/nsswitch.conf | grep hosts # 2 看解析顺序：files 与 dns 谁在前
resolvectl status 2>/dev/null | head -20 # 3 本机解析器配置与当前使用的上游
dig @8.8.8.8 www.example.com +short # 4 递归器视角：公共解析器能否得到答案
dig +norecurse @ns1.example.com www.example.com A # 5 权威视角：直接问该域的权威服务器
dig +trace www.example.com | tail -20 # 6 全链路委派：从根一路看到权威现象与最可能层级
| 现象 | 定位方向 | 先做什么 |
|---|---|---|
| ping 域名失败但 dig 正常 | 应用或 NSS 或 hosts 层 | 用 getent 复现，检查 hosts 与 nsswitch |
| 所有域名解析都慢 | 本机 DNS 超时或网络问题 | 换一个上游解析器对比，抓包看是否超时 |
| 单个域名 SERVFAIL | 该域权威或 DNSSEC 配置异常 | 直连权威查询并检查 DNSSEC 链 |
| 换网络后恢复正常 | 本地递归器被污染或被劫持 | 对比默认解析器与公共解析器结果 |
| 新记录迟迟不生效 | 负缓存或旧 TTL 尚未过期 | 查各级缓存剩余时间并等待或刷新 |
| 只在部分客户端失败 | 客户端缓存或分流策略差异 | 分别在两端执行 getent 与 dig 对比 |
典型使用场景
- 业务上线后域名解析失败，需要快速判断是权威未生效还是客户端缓存
- 跨运营商访问异常的定位，比较不同上游解析器的返回差异
- 邮件投递异常时确认 MX 记录与 SPF 相关记录是否正确下发
- 排查间歇性解析失败，判断是否由 DNSSEC 校验失败引起
- 迁移解析服务商时验证新旧权威返回是否一致
dig 输出读法
| 字段 | 含义 | 怎么看 |
|---|---|---|
| status | NOERROR 与 NXDOMAIN 与 SERVFAIL 与 REFUSED | SERVFAIL 往上游查，REFUSED 说明对方拒绝递归 |
| ANSWER SECTION | 最终答案记录与 TTL | 与预期值逐个核对，注意 TTL 剩余秒数 |
| AUTHORITY SECTION | 权威服务器与 SOA 信息 | 判断答案来自缓存还是权威 |
| ADDITIONAL SECTION | 附加记录，如 NS 的地址 | 排查粘合记录缺失时看这里 |
| query time | 查询耗时 | 明显偏高常见于上游超时后重试 |
| SERVER | 实际应答的服务器地址 | 确认到底问的是谁，别误读结果 |
对比「指定公共解析器」与「使用系统默认解析器」的结果差异，是判断污染与劫持最快的一刀；两者不一致时，问题多半出在本地递归器或链路上的中间设备。
排查顺序上先固定结论再动配置：确认每一层的实际返回之后，再决定改哪一层。多改一处会让下一次验证失去对照，反而延长故障时间。