Linux DNS 解析故障排查：从 dig 到 resolv.conf 的完整路径

DNS 解析出问题时的表现很统一：ping 域名报「域名解析暂时失败」，curl 卡很久才超时，但直接 ping IP 却是通的。这说明网络连通没问题，故障在域名解析这一层。排查的关键是按解析的实际顺序一层层验证，而不是上来就改配置。

第一步先分清「解析失败」和「解析结果不对」。用 dig 或直接打 nslookup 查目标域名，比如 dig 后面跟上要查的域名。看返回里的 status 字段，NXDOMAIN 是域名不存在，SERVFAIL 多半是上游递归服务器出了问题，NOERROR 但没 A 记录则可能是记录类型配错。如果 dig 直接超时，先查默认 DNS 服务器：dig 命令默认用的是 /etc/resolv.conf 里的 nameserver，可以显式指定一台公共 DNS 对比（比如 223.5.5.5），指定服务器能解、默认的不能解，问题就锁定在本机配置的 DNS 服务器上。

第二步看 resolv.conf 本身。cat /etc/resolv.conf，确认 nameserver 指向的地址是公司内网 DNS、网关还是公共 DNS，再 ping 一下这个地址确认可达。注意这个文件经常被覆盖：CentOS 上由 NetworkManager 管理，Ubuntu 18 以后由 systemd-resolved 管理，容器里是 Docker 写入的。手动改完重启或续租 DHCP 后被还原是常见现象，要改应该改 NetworkManager 的 DNS 配置或 netplan/netconfig，而不是直接改文件。resolved 系统上 resolv.conf 实际指向 127.0.0.53，这时要用 resolvectl status 和 resolvectl query 看真实生效的上游。

第三步检查本地缓存和 hosts。很多机器跑着 nscd 或 systemd-resolved，解析结果会被缓存，改完配置感觉不生效先清缓存：resolvectl flush-caches 或重启 nscd。/etc/hosts 优先级最高（由 /etc/nsswitch.conf 的 hosts 行决定，默认 files 在 dns 之前），开发机上人为写的静态映射忘了删，是「别人能解析我不能」的常见原因。遇到解析结果和 dig 不一致时，先 grep 一下 hosts。

第四步处理特殊场景。Docker 容器内解析不了，先看容器的 /etc/resolv.conf 是否继承了宿主机能用的 nameserver；容器跑在不能访问内网 DNS 的网络命名空间里也很常见。K8s 里则是看 CoreDNS 的日志和 pod 的 dnsPolicy。超时类故障注意 dig 的默认超时和重试逻辑：应用里解析慢但 dig 正常，往往是应用使用的超时太短，或 glibc resolver 的 options timeout/attempts 需要调。

最后记一个经验：把「域名解析失败」当成结果而不是原因。先 dig 指定 DNS 缩小范围，再查 resolv.conf 的来源是谁管理的，再排缓存和 hosts，最后才怀疑网络或上游。按这个顺序，绝大多数 DNS 故障五分钟内能定位到层。