DNS解析失败通常表现为域名无法访问但IP可通，常见原因包括/etc/resolv.conf配置错误、网络不通、上游DNS故障或防火墙拦截。首先检查/etc/resolv.conf中nameserver是否有效，使用dig @指定DNS测试解析能力；若公共DNS（如8.8.8.8）可解析而本地DNS不行，则问题在本地DNS或网络路径。通过ping、ip a、ip route确认网络连通性，确保网卡激活且路由正确。检查/etc/nsswitch.conf中hosts行是否包含dns，防止解析顺序错误。对于systemd-resolved系统，用resolvectl status查看DNS状态，必要时重启服务。排查防火墙是否阻止UDP 53端口，并查看journalctl日志获取线索。高级诊断可用tcpdump抓DNS流量，strace追踪程序调用，getent hosts验证NSS机制，临时修改resolv.conf测试公共DNS，或检查/etc/hosts是否存在错误映射。综合这些步骤可精准定位是本地配置还是上游问题。
Linux上诊断DNS解析失败，核心在于系统地排查网络配置、DNS服务器设置以及本地解析器状态。这通常意味着从本地配置文件入手，逐步验证网络连通性，并最终确认上游DNS服务器是否正常响应。
解决方案
当我遇到Linux系统上DNS解析失败的情况，比如
ping google.com提示
Temporary failure in name resolution，或者
curl无法连接到域名，我的第一反应是：这多半是
/etc/resolv.conf出了问题，或者是网络根本就没通。解决这类问题，我通常会按以下步骤来。
首先，我会直接查看
/etc/resolv.conf文件。这是Linux系统进行DNS查询的“指南针”。
cat /etc/resolv.conf
这里面应该有至少一行
nameserver，后面跟着一个IP地址，这就是你的系统用来查询域名的DNS服务器。如果这个文件是空的，或者指向了一个错误的IP，那问题就显而易见了。有时候，这个文件会被网络管理工具（比如NetworkManager或systemd-resolved）动态生成或覆盖，所以即使你手动修改了，也可能在重启网络后失效。我还会留意
search关键字，它定义了在解析短主机名时会尝试的域名后缀。
如果
nameserver地址看起来没问题，我会尝试直接测试这些DNS服务器。
dig @example.com
例如，如果
/etc/resolv.conf里写的是
nameserver 192.168.1.1，我就会运行
dig @192.168.1.1 google.com。如果这个命令成功返回了IP地址，说明DNS服务器本身是工作的。如果失败，那可能就是DNS服务器有问题，或者我的机器根本无法连接到它。为了进一步验证，我还会尝试公共DNS服务器，比如Google的
8.8.8.8：
dig @8.8.8.8 google.com。如果公共DNS能解析，而我的配置的DNS不行，那问题就指向了我的本地DNS服务器或网络路径。
接着，我会检查网络连通性。如果DNS服务器都ping不通，那解析失败也就不足为奇了。
ping -c 3
如果ping不通，我就会检查我的网络接口是否正常工作：
ip a ip route
确认网卡是否激活，IP地址和子网掩码是否正确，以及默认网关是否指向了正确的路由器。有时候，最简单的网络配置错误，比如IP地址冲突或者网线没插好，就会导致一系列看似复杂的DNS问题。
再深挖一点，我会检查
/etc/nsswitch.conf。这个文件决定了系统查找主机名、密码等信息的顺序。确保
hosts:这一行包含了
dns，例如
hosts: files dns。这意味着系统会先检查
/etc/hosts文件，然后才去查询DNS。如果这里配置不当，DNS查询可能根本就不会被触发。
对于使用
systemd-resolved的系统，情况会稍微复杂一些。
/etc/resolv.conf往往是一个符号链接，指向
/run/systemd/resolve/stub-resolv.conf或
/run/systemd/resolve/resolv.conf。我会用
resolvectl status来查看
systemd-resolved的当前状态、配置的DNS服务器以及缓存情况。
systemctl status systemd-resolved resolvectl status resolvectl query example.com
如果
systemd-resolved出现问题，重启服务
sudo systemctl restart systemd-resolved有时能解决。
最后，防火墙也是一个不能忽视的因素。虽然不常见，但如果本地防火墙（如
firewalld或
ufw）阻止了UDP 53端口的对外连接，那DNS查询自然无法进行。
sudo firewall-cmd --list-all sudo ufw status
我还会检查系统日志，特别是
journalctl -u systemd-resolved或
dmesg，看看有没有相关的错误信息，这些往往能提供一些线索。
DNS解析失败通常有哪些常见迹象？
当Linux系统遭遇DNS解析失败时，它往往不会直接告诉你“DNS挂了”，而是以各种各样的应用层错误来表现。在我看来，最明显的几个迹象包括：
首先，最直观的，就是浏览器无法打开网页。你会看到浏览器显示“此站点无法访问”、“DNS_PROBE_FINISHED_NXDOMAIN”或者类似的错误信息。这几乎是DNS问题的标志性表现。
其次，命令行工具通过域名访问失败，但通过IP地址访问成功。这是一个非常关键的诊断点。比如，你尝试
ping google.com可能会得到
Temporary failure in name resolution或
Name or service not known的错误，但如果
ping 142.250.187.174(Google的一个IP) 却能正常通达。同样，
ssh user@yourserver.com失败，但
ssh user@192.168.1.100成功，这都强烈指向DNS问题。
再者，软件包管理器无法更新或安装软件。当你运行
sudo apt update或
sudo yum update时，如果遇到类似“无法解析域名”的错误，导致无法连接到软件源服务器，那也是DNS解析失败的典型症状。因为这些工具在连接到仓库之前，需要先解析仓库的域名。
还有，邮件客户端、即时通讯工具等依赖域名服务的应用无法正常工作。它们在连接服务器时也需要进行DNS查询，一旦失败，就会表现为无法登录、无法发送/接收消息等。
最后，系统日志中出现与名称解析相关的错误。通过
journalctl -f实时查看日志，或者查看
/var/log/syslog、
/var/log/messages等文件，可能会发现
Name resolution failed、
Could not resolve host或
Temporary failure in name resolution等明确的错误信息。这些日志是深层诊断的重要依据。
如何区分是本地配置问题还是上游DNS服务器问题？
区分DNS解析失败是本地配置问题还是上游DNS服务器问题，是我在排查时的一个核心思路。这就像医生诊断病症，要先确定是病人自身器官有问题，还是外部环境出了状况。
我的方法是进行“隔离测试”。
判断是否是本地配置问题：
如果以下情况发生，那么问题很可能出在你的本地系统配置上：
-
/etc/resolv.conf
文件异常： 比如文件是空的，或者nameserver
IP地址是错误的、不可达的（例如，指向了你局域网内根本不存在的IP），或者指向了一个内网DNS服务器，而这个服务器本身又没有正确配置。 -
网络接口或路由问题： 你的网卡可能没有正确获取IP地址，或者默认网关配置错误，导致你的机器根本无法将DNS请求发送出去。
ip a
和ip route
的输出会帮你判断。如果ping
都失败了，那肯定不是DNS服务器的问题，而是你机器的网络路径问题。 -
本地防火墙阻挡： 你的Linux系统上运行的防火墙（如
firewalld
或ufw
）可能意外地阻止了UDP 53端口的对外连接。这是比较少见，但确实会发生。 -
nsswitch.conf
配置不当： 如果/etc/nsswitch.conf
中的hosts:
这一行没有包含dns
，或者files
在dns
之前有错误的条目，系统可能就不会去查询DNS。 -
systemd-resolved
或其他本地DNS缓存服务故障： 如果你的系统使用了systemd-resolved
或dnsmasq
等本地DNS缓存服务，而它们本身出现了故障或配置错误，即使上游DNS服务器正常，本地解析也可能失败。这时，resolvectl status
或sudo systemctl status dnsmasq
会显示异常。
判断是否是上游DNS服务器问题：
如果以下情况发生，那么问题更可能出在你配置的上游DNS服务器上：
-
dig @
失败，但example.com dig @8.8.8.8 example.com
成功： 这是最直接的证据。这意味着你的系统能够正常发送DNS请求，并且公共DNS服务器能够响应，但你/etc/resolv.conf
中配置的DNS服务器却无法响应或返回错误。 -
ping
成功，但dig @
失败： 这表明你的机器可以到达DNS服务器，但服务器本身没有提供正确的DNS服务（可能宕机、过载或配置错误）。example.com - 所有客户端都无法解析： 如果你局域网内的所有设备（包括Windows、macOS等）都无法解析域名，并且它们都使用同一个DNS服务器（比如你的路由器IP），那么很可能是路由器提供的DNS服务出了问题，或者路由器转发的上游DNS服务器出了问题。
简而言之，我的诊断流程是：先确保自己的机器能“说话”（网络通畅，本地配置正确），再看“听众”（上游DNS服务器）是否能“回应”。如果我的机器用公共DNS能解析，但用自己配置的DNS不能，那八成是自己配置的DNS服务器有问题。
解决DNS解析问题时，有哪些高级技巧或工具可以利用？
在处理那些棘手的DNS解析问题时，除了常规的
dig和
ping，我还有一些更深入的技巧和工具可以利用，它们能帮助我看到表面之下发生的事情。
1. tcpdump
或 Wireshark
抓包分析：
这是我最喜欢也是最强大的工具之一。如果我怀疑DNS请求根本没有发出，或者发出了但没有收到响应，或者收到了错误的响应，
tcpdump能给我答案。
sudo tcpdump -i any port 53 -nn
这个命令会监听所有网络接口上所有UDP/TCP 53端口的流量。当我尝试
ping google.com时，我会看到我的机器是否发出了DNS查询请求（通常是UDP），以及是否有来自DNS服务器的响应。如果我看到查询请求发出去了，但长时间没有响应，或者响应是
NXDOMAIN（域名不存在），这就能提供非常具体的线索。
Wireshark提供了更友好的图形界面和更强大的协议分析能力。
2. strace
追踪系统调用：
当一个程序（比如
curl或
wget）解析域名失败时，我可能会用
strace来看看它在底层做了什么。
strace -e trace=network,file -f
strace可以显示程序打开了哪些文件（比如
/etc/resolv.conf、
/etc/nsswitch.conf），以及进行了哪些网络相关的系统调用（如
socket、
connect、
sendto、
recvfrom）。这能帮助我确认程序是否尝试读取了正确的配置文件，以及是否尝试向正确的IP地址发送了DNS请求。
3. getent hosts
验证NSS配置：
getent命令会按照
/etc/nsswitch.conf中定义的顺序，查询各种数据库。
getent hosts example.com
如果
getent hosts无法解析，而
dig却可以，这通常意味着
/etc/nsswitch.conf配置有问题，或者本地的
nscd(Name Service Cache Daemon) 缓存服务有问题。
4. 临时修改 /etc/resolv.conf
进行快速测试：
如果我怀疑当前配置的DNS服务器有问题，我不会立即去修改NetworkManager的配置，而是会临时覆盖
/etc/resolv.conf来测试公共DNS。
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf echo "nameserver 1.1.1.1" | sudo tee -a /etc/resolv.conf
然后尝试解析。如果成功了，我就知道问题出在原来的DNS服务器上。测试完毕后，通常重启网络服务（如
sudo systemctl restart NetworkManager）就能恢复到之前的配置，或者手动删除这些临时添加的行。
5. 检查 /etc/hosts
文件：
这是一个非常基础但又容易被忽视的地方。
/etc/hosts文件拥有最高的解析优先级。如果某个域名在这里被错误地指向了某个IP，或者被指向了
127.0.0.1，那么即使你的DNS配置完全正确，该域名也无法被正确解析。
cat /etc/hosts
6. host
命令：
虽然
dig更强大，但
host命令在某些场景下更简洁，尤其适合快速查询一个域名的A记录。
host example.com host -t MX example.com # 查询邮件交换记录
这些工具和技巧，让我能更深入地剖析DNS解析失败的根源，而不是停留在表面的猜测。它们帮助我从网络底层、系统配置和应用行为等多个维度，构建出问题发生的全貌。
