在 Linux 系统中遇到 DNS 解析失败（例如 ping 域名提示 unknown host 或 curl 报错 Could not resolve host）时，需要按照从本地到网络、从配置到服务的顺序进行系统性排查。以下为专业、完整的故障处理方法。
第一步，确认 网络连通性。先检查本机是否具备基本网络通信能力，执行 ip addr show 查看网卡是否获得 IP 地址，或使用 ip route show 确认默认路由存在。若网络本身不通，DNS 解析自然也会失败，此时应优先修复物理链路、DHCP 或静态 IP 配置。
第二步，检查 DNS 客户端配置文件。Linux 传统上使用 /etc/resolv.conf 文件配置 DNS 服务器，该文件中的 nameserver 行指定了用于解析的服务器地址。使用 cat /etc/resolv.conf 查看内容，确保至少有一个可用的 nameserver，例如 nameserver 223.5.5.5 或 nameserver 114.114.114.114。如果文件为空或仅包含注释，则解析必然失败，需要添加或修改为合法的 DNS 服务器地址。
第三步，测试 DNS 服务器可达性。使用 ping -c 4 223.5.5.5 或 traceroute 判断能否访问该 DNS 服务器的 IP 地址。若无法 ping 通，说明到 DNS 服务器之间的网络路径存在问题；若可以 ping 通但解析依然失败，则可能是 DNS 服务自身无响应或配置错误。
第四步，使用 dig 或 nslookup 工具进行定向解析测试。执行 dig @223.5.5.5 www.example.com，其中 @ 后显式指定 DNS 服务器，以绕过本机默认配置。如果指定服务器能返回正确结果，说明是本地配置问题；如果仍然超时或返回 NXDOMAIN，则可能是上游 DNS 服务器故障、域名不存在或域名被劫持。
第五步，检查 /etc/nsswitch.conf 中 hosts 条目的解析顺序。该文件控制系统使用哪些数据库进行主机名解析，典型配置为 hosts: files dns，表示先查 /etc/hosts 文件，再查 DNS。若误改为 hosts: files 或顺序异常，会导致域名完全不走 DNS 解析。应确保包含 dns 并放在正确位置。
第六步，排查 /etc/hosts 文件干扰。如果 /etc/hosts 中存在待解析域名的错误映射（例如将 example.com 指向 127.0.0.1 或已废弃 IP），则会覆盖 DNS 结果。检查是否有异常条目，必要时临时移除或注释掉，再重新测试解析。
第七步，关注 systemd-resolved 或 NetworkManager 等现代网络服务的影响。许多 Linux 发行版使用 systemd-resolved 管理 DNS，并通过 /run/systemd/resolve/stub-resolv.conf 或动态生成的配置文件覆盖 /etc/resolv.conf。执行 systemctl status systemd-resolved 查看状态，使用 resolvectl status 查看实际生效的 DNS 服务器。若此服务因缓存或配置错误导致解析异常，可尝试 sudo systemctl restart systemd-resolved 重启服务，或 resolvectl flush-caches 清空缓存。
第八步，检查 /etc/resolv.conf 是否被 NetworkManager 或 dhclient 覆盖。执行 ls -l /etc/resolv.conf 查看它是否为符号链接。如果是指向 /run/systemd/resolve/stub-resolv.conf 或 /run/resolvconf 的链接，则直接编辑它可能被覆盖。需要根据所使用的网络管理工具调整配置，或在 NetworkManager 的连接配置中正确设置 DNS，然后重新激活连接。
第九步，排查 防火墙或安全策略。DNS 使用 UDP 53 端口 和 TCP 53 端口，本机防火墙或 iptables 规则可能阻止了对外部 DNS 服务器的访问。执行 sudo iptables -L -n 或 sudo firewall-cmd --list-all 检查放行状态。同时，某些云服务器或企业内部网络的安全组也可能屏蔽 DNS 流量，需要确认出站策略。
第十步，验证 DNS 解析器软件本身。如果系统使用了 dnsmasq、unbound 等本地缓存转发服务，它们可能因缓存污染、上游配置错误或监听端口冲突而故障。使用 systemctl status dnsmasq 查看状态，检查 /etc/dnsmasq.conf 和 /etc/dnsmasq.d/ 下的配置，必要时临时停止服务来绕过回环测试。
第十一步，针对 IPv6 与 IPv4 双栈进行特殊检查。如果系统优先使用 AAAA 记录但 IPv6 路由不可用，可能表现为偶发性解析失败。可通过修改 /etc/gai.conf 或强制使用 IPv4（例如 curl -4）来测试。另外，某些 DNS 服务器可能只支持 IPv4，不支持 IPv6 查询，需要确保配置了合法的 IPv6 DNS 地址（例如 2400:3200::1 或 2001:4860:4860::8888）。
第十二步，检查 DNS 超时与重试参数。Linux 默认的 glibc 解析器会按顺序查找所有 nameserver，超时时间较长。如果第一个 nameserver 不可用，整个解析过程会变得缓慢，最终失败。可以在 /etc/resolv.conf 中设置 options timeout:2 attempts:2 减少等待时间，但核心问题仍需找到不可用的服务器并移除。
第十三步，考虑 域名本身的权威 DNS 故障。使用 dig NS example.com 查询顶级域服务器，再使用 dig @该顶级域服务器 example.com 查询权威 NS 记录，最后用 dig @权威服务器 example.com 获取 A 记录。如果整个链路都无法返回结果，则域名可能已过期、NS 配置错误或权威服务器宕机，这需要联系域名管理者处理。
第十四步，处理 glibc 解析器配置文件损坏。如果 /etc/resolv.conf 语法错误（例如缺少 domain、search 或 nameserver 关键字），也会导致解析失败。标准格式示例为：search example.com，nameserver 8.8.8.8。避免使用不支持的选项，并使用 chattr 或编辑器修改后验证。
第十五步，执行 strace 或 tcpdump 进行底层诊断。以 sudo tcpdump -i eth0 udp port 53 抓取 DNS 请求包，观察是否有请求发出、发往哪个 IP、是否有响应。若服务器开启 DNSSEC 验证，还需检查 /etc/dnssec-trigger.conf 或 systemd-resolved 的 DNSSEC 模式设置，错误的 DNSSEC 配置会导致解析被拒绝。
第十六步，最终终极措施：重启相关服务或系统。执行 sudo systemctl restart NetworkManager、sudo systemctl restart systemd-resolved，或彻底清空 iptables 规则后重试。若所有配置均正确仍无法解析，可尝试使用 busybox nslookup 或 drill 等替代工具排除 glibc 库问题。如果其他主机正常，只有当前主机异常，则可能是 glibc 版本缺陷或 NSS module（如 libnss_resolve）损坏，考虑升级或重装相关软件包。
综上，Linux DNS 解析失败的原因涉及 网络配置、系统文件、DNS 服务、防火墙、IPv6、DNSSEC 等多个层面。排查思路应遵循“先链路后解析，先本地后上游”，每一步使用专业工具验证，并注意现代化网络管理服务对传统配置文件的覆盖机制。熟练掌握 dig、nslookup、systemd-resolve、tcpdump 等工具，可显著提升故障定位效率。
查看详情
查看详情
