Linux怎么诊断DNS解析失败

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

cat /etc/resolv.conf

这里面应该有至少一行

nameserver

search

如果

nameserver

dig @<nameserver_ip_from_resolv.conf> example.com

例如，如果

/etc/resolv.conf

nameserver 192.168.1.1

dig @192.168.1.1 google.com

8.8.8.8

dig @8.8.8.8 google.com

接着，我会检查网络连通性。如果DNS服务器都ping不通，那解析失败也就不足为奇了。

ping -c 3 <nameserver_ip>

如果ping不通，我就会检查我的网络接口是否正常工作：

ip a
ip route

确认网卡是否激活，IP地址和子网掩码是否正确，以及默认网关是否指向了正确的路由器。有时候，最简单的网络配置错误，比如IP地址冲突或者网线没插好，就会导致一系列看似复杂的DNS问题。

再深挖一点，我会检查

/etc/nsswitch.conf

hosts:

dns

hosts: files dns

/etc/hosts

对于使用

systemd-resolved

/etc/resolv.conf

/run/systemd/resolve/stub-resolv.conf

/run/systemd/resolve/resolv.conf

resolvectl status

systemd-resolved

systemctl status systemd-resolved
resolvectl status
resolvectl query example.com

如果

systemd-resolved

sudo systemctl restart systemd-resolved

最后，防火墙也是一个不能忽视的因素。虽然不常见，但如果本地防火墙（如

firewalld

ufw

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

ssh user@yourserver.com

ssh user@192.168.1.100

再者，软件包管理器无法更新或安装软件。当你运行

sudo apt update

sudo yum update

成功失败消息弹窗样式设置模板

一款成功失败消息弹窗样式设置模板

23

查看详情

还有，邮件客户端、即时通讯工具等依赖域名服务的应用无法正常工作。它们在连接服务器时也需要进行DNS查询，一旦失败，就会表现为无法登录、无法发送/接收消息等。

最后，系统日志中出现与名称解析相关的错误。通过

journalctl -f

/var/log/syslog

/var/log/messages

Name resolution failed

Could not resolve host

Temporary failure in name resolution

如何区分是本地配置问题还是上游DNS服务器问题？

区分DNS解析失败是本地配置问题还是上游DNS服务器问题，是我在排查时的一个核心思路。这就像医生诊断病症，要先确定是病人自身器官有问题，还是外部环境出了状况。

我的方法是进行“隔离测试”。

判断是否是本地配置问题：

如果以下情况发生，那么问题很可能出在你的本地系统配置上：

1. /etc/resolv.conf

   登录后复制
   文件异常： 比如文件是空的，或者

   nameserver

   登录后复制
   IP地址是错误的、不可达的（例如，指向了你局域网内根本不存在的IP），或者指向了一个内网DNS服务器，而这个服务器本身又没有正确配置。
2. 网络接口或路由问题： 你的网卡可能没有正确获取IP地址，或者默认网关配置错误，导致你的机器根本无法将DNS请求发送出去。

   ip a

   登录后复制
   和

   ip route

   登录后复制
   的输出会帮你判断。如果

   ping <nameserver_ip>

   登录后复制
   都失败了，那肯定不是DNS服务器的问题，而是你机器的网络路径问题。
3. 本地防火墙阻挡： 你的Linux系统上运行的防火墙（如

   firewalld

   登录后复制
   或

   ufw

   登录后复制
   ）可能意外地阻止了UDP 53端口的对外连接。这是比较少见，但确实会发生。

4. nsswitch.conf

   登录后复制
   配置不当： 如果

   /etc/nsswitch.conf

   登录后复制
   中的

   hosts:

   登录后复制
   这一行没有包含

   dns

   登录后复制
   ，或者

   files

   登录后复制
   在

   dns

   登录后复制
   之前有错误的条目，系统可能就不会去查询DNS。

5. systemd-resolved

   登录后复制
   或其他本地DNS缓存服务故障： 如果你的系统使用了

   systemd-resolved

   登录后复制
   或

   dnsmasq

   登录后复制
   等本地DNS缓存服务，而它们本身出现了故障或配置错误，即使上游DNS服务器正常，本地解析也可能失败。这时，

   resolvectl status

   登录后复制
   或

   sudo systemctl status dnsmasq

   登录后复制
   会显示异常。

判断是否是上游DNS服务器问题：

如果以下情况发生，那么问题更可能出在你配置的上游DNS服务器上：

1. dig @<your_configured_nameserver_ip> example.com

   登录后复制
   失败，但

   dig @8.8.8.8 example.com

   登录后复制
   成功： 这是最直接的证据。这意味着你的系统能够正常发送DNS请求，并且公共DNS服务器能够响应，但你

   /etc/resolv.conf

   登录后复制
   中配置的DNS服务器却无法响应或返回错误。

2. ping <your_configured_nameserver_ip>

   登录后复制
   成功，但

   dig @<your_configured_nameserver_ip> example.com

   登录后复制
   失败： 这表明你的机器可以到达DNS服务器，但服务器本身没有提供正确的DNS服务（可能宕机、过载或配置错误）。
3. 所有客户端都无法解析： 如果你局域网内的所有设备（包括Windows、macOS等）都无法解析域名，并且它们都使用同一个DNS服务器（比如你的路由器IP），那么很可能是路由器提供的DNS服务出了问题，或者路由器转发的上游DNS服务器出了问题。

简而言之，我的诊断流程是：先确保自己的机器能“说话”（网络通畅，本地配置正确），再看“听众”（上游DNS服务器）是否能“回应”。如果我的机器用公共DNS能解析，但用自己配置的DNS不能，那八成是自己配置的DNS服务器有问题。

解决DNS解析问题时，有哪些高级技巧或工具可以利用？

在处理那些棘手的DNS解析问题时，除了常规的

dig

ping

1.

tcpdump

Wireshark

tcpdump

sudo tcpdump -i any port 53 -nn

这个命令会监听所有网络接口上所有UDP/TCP 53端口的流量。当我尝试

ping google.com

NXDOMAIN

Wireshark

2.

strace

curl

wget

strace

strace -e trace=network,file -f <command_that_fails>

strace

/etc/resolv.conf

/etc/nsswitch.conf

socket

connect

sendto

recvfrom

3.

getent hosts <hostname>

getent

/etc/nsswitch.conf

getent hosts example.com

如果

getent hosts

dig

/etc/nsswitch.conf

nscd

4. 临时修改

/etc/resolv.conf

/etc/resolv.conf

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

127.0.0.1

cat /etc/hosts

6.

host

dig

host

host example.com
host -t MX example.com # 查询邮件交换记录

这些工具和技巧，让我能更深入地剖析DNS解析失败的根源，而不是停留在表面的猜测。它们帮助我从网络底层、系统配置和应用行为等多个维度，构建出问题发生的全貌。

以上就是Linux怎么诊断DNS解析失败的详细内容，更多请关注php中文网其它相关文章！