Linux 下排查 DNS 解析故障的五步法

在日常运维里，"网页打不开"十有八九和 DNS 有关。很多人第一反应是重启网络，但只要按顺序排查，几分钟就能定位问题。下面是我常用的五步法，适用于主流 Linux 发行版。

第一步：确认是不是 DNS 的问题

先用 ping 一个公网 IP，比如 ping -c 3 223.5.5.5。如果 IP 能通而域名不通，基本可以锁定是解析环节出了问题；如果 IP 也不通，应先检查网关、路由和防火墙，而不是盯着 DNS。

第二步：看系统到底在用哪个 DNS

查看 /etc/resolv.conf 中的 nameserver。在使用 systemd-resolved 的系统上，这里往往是 127.0.0.53，真正的上游需要用 resolvectl status 查看。很多"改了 DNS 不生效"的问题，都是因为改错了文件，或者被 NetworkManager、DHCP 重新覆盖。

第三步：直接向上游提问

用 dig example.com @223.5.5.5 和 dig example.com @119.29.29.29 分别查询。如果指定上游能解析、默认却不行，问题在本机配置或本地缓存；如果所有上游都失败，可能是域名本身的记录有问题，可以用 dig +trace 从根服务器逐级追踪，看在哪一级断掉。

第四步：检查缓存与 hosts

/etc/hosts 的优先级通常高于 DNS，一条遗忘的旧记录就可能让域名指向错误的地址。解析顺序由 /etc/nsswitch.conf 中的 hosts 一行决定。若使用 systemd-resolved，可以执行 resolvectl flush-caches 清空缓存后再测试；用 getent hosts example.com 能看到应用程序真正拿到的结果，比 dig 更贴近实际。

第五步：留意 MTU、IPv6 与防火墙

有些网络会丢弃较大的 UDP 包，导致带 DNSSEC 或记录较多的响应失败，可以用 dig +tcp 对比测试。另外，如果 AAAA 记录可以解析但 IPv6 线路不通，程序会先尝试 IPv6 再超时回退，表现为"打开很慢"。最后确认防火墙和安全组放行了 53 端口的 UDP 和 TCP 出站流量。

小结

排查 DNS 的关键是分层：先确认网络可达，再确认用的是哪个解析器，然后绕过本机直接问上游，最后再看缓存、hosts 和传输层细节。把这五步做成一个小脚本放在服务器上，下次遇到问题时能省下不少时间。在华为云 ECS 上，也可以结合 VPC 的内网 DNS 和云解析服务，按同样的思路逐层定位。