CentOS7域名解析失败时，先别急着改配置文件按“查resolv.conf→验证DNS连通→检查网卡与路由→排查防火墙”的顺序操作，多数情况能在十分钟内定位问题。域名解析的本质是把域名翻译成IP地址，一旦这个环节出错，服务器就会陷入“能ping通IP却上不了网”的怪圈，下面咱们按实际排查路径,一步步拆解。
CentOS7域名解析失败怎么排查：从resolv.conf到网络连接
第一步：确认resolv.conf有没有被“劫持”
登录服务器后,第一件事是查看当前的DNS配置：
cat /etc/resolv.conf
正常输出应该包含nameserver行，
nameserver 223.5.5.5
nameserver 8.8.8.8如果你发现这个文件内容是空的，或者nameserver指向了0.0.1或0.0.53，那问题就清晰了DNS请求压根没发出去。
注意： CentOS7的/etc/resolv.conf有可能是软链接，指向/run/systemd/resolve/stub-resolv.conf，这种情况下，直接改resolv.conf是没用的，系统重启后会被覆盖，用ls -l /etc/resolv.conf看一眼就能确认。
业内专家指出，CentOS7里“resolv.conf被覆盖”是排障时最容易踩的坑,多半和NetworkManager或dhclient的行为有关。
第二步：用nslookup快速验证“能不能解析”
修改配置文件之前,先做一次简单测试：
nslookup www.baidu.com
如果返回server can't find www.baidu.com，说明DNS服务器没响应,这时候换一个公共DNS再试一次：
nslookup www.baidu.com 223.5.5.5
结果正常的话，基本可以判断是原DNS服务器不可用，如果报connection timed out，那就要怀疑网络链路本身有问题比如防火墙挡了UDP 53端口,或者路由不通。
一个小经验： 同机房的另一台服务器能正常解析时，先对比两台机器的/etc/resolv.conf差异,往往能直接看出问题。
centos7 DNS配置文件详解：resolv.conf被覆盖的真相
谁在偷偷改你的DNS设置？
CentOS7默认使用NetworkManager管理网络，你手动改了/etc/resolv.conf，但只要执行了nmcli connection reload或者重启网络服务,NetworkManager就会按照网卡配置里的DNS设置重新生成这个文件。
典型场景： 你用nmcli connection modify eth0 ipv4.dns "8.8.8.8"设置了DNS，觉得万事大吉，却忘了把ipv4.ignore-auto-dns设为yes，DHCP一续约,原来的DNS又回来了。
处理方式：
- 查看当前活跃连接：
nmcli connection show --active - 修改网卡DNS：
nmcli connection modify eth0 ipv4.dns "223.5.5.5 119.29.29.29" ipv4.ignore-auto-dns yes - 让配置生效：
nmcli connection up eth0
这套操作的好处是，NetworkManager会自己更新resolv.conf,不用手动去改这个文件。
不用NetworkManager的话，怎么改才持久？
有些服务器为了省资源会禁用NetworkManager，直接用/etc/sysconfig/network-scripts/ifcfg-eth0这个配置文件来管理网络，这种情况下,检查网卡配置文件里有没有这几行：
DNS1=223.5.5.5
DNS2=119.29.29.29
PEERDNS=noPEERDNS=no是关键，它的意思是：即使DHCP下发了DNS，也不要用,改完以后重启网络服务让配置生效：
systemctl restart network
用nslookup和dig定位解析失败的具体原因
区分“解析慢”和“解析失败”
DNS故障不一定表现为完全没响应，有时候是慢得要命，用dig命令可以看具体耗时：
dig www.baidu.com
输出里有个Query time:字段，如果数值在几百到上千毫秒，说明DNS服务器响应缓慢，这时候换一个低延迟的公共DNS，比如简米云的223.5.5.5或酷番云的119.29.29.29,效果立竿见影。
检查UDP 53端口是否被防火墙拦截
DNS默认走UDP 53端口，少数情况下防火墙会把这条链路挡掉,测试方法：
iptables -L -n | grep 53
或者查看firewalld的规则：
firewall-cmd --list-all
如果发现53端口被DROP,追加放行规则：
iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
这类问题在生产环境里不算少见尤其是刚做完安全加固的机器,iptables规则把出方向的DNS请求一并拦了。
系统里没有dig和nslookup怎么办？
最小化安装的CentOS7可能没带这两个工具,可以用：
yum install -y bind-utils
装完之后nslookup、dig、host就都齐了，这条命令本身也值得记住，因为排查DNS问题绕不开bind-utils这个包。
域名能解析但服务器上不了网：检查路由与防火墙
先确认默认网关和路由表
DNS解析成功但网络还是不通，就要往回看一层，用ip route查看默认路由：
ip route | grep default
正常的输出类似：
default via 192.168.1.1 dev eth0如果没有任何输出，说明没有默认网关，这种情况下就算DNS配置得再对，数据包也发不出去,临时加一条默认路由可以用：
ip route add default via 192.168.1.1 dev eth0
但要永久生效,还是得写进网卡配置文件：
GATEWAY=192.168.1.1
DEFROUTE=yes改完以后可能有台机器要重启网络服务才认账。
排查链路：从网关到外部DNS逐层ping
把排查逻辑拉成一条直线,从近到远逐层验证：
- 先ping网关，确认局域网通不通：
ping -c 3 192.168.1.1 - 再ping一个公网IP，排除域名解析干扰：
ping -c 3 223.5.5.5 - 最后ping域名，验证DNS解析+网络双链路：
ping -c 3 www.baidu.com
如果第一步就失败，问题出在二层链路检查网线、交换机端口、网卡链路状态（ethtool eth0），如果第二步失败，路由或出网防火墙有问题，只有第三步失败,才值得回头抠DNS配置。
实测过的一个例子： 某台简米云ECS上，ping 114.114.114.114通，但
ping www.baidu.com提示unknown host，最后查明是安全组规则只放行了ICMP没放行UDP 53，加一条允许UDP 53出口的规则就好了。
别忽略/etc/hosts文件的干扰
/etc/hosts里如果写死了某条域名映射，会优先于DNS查询生效，曾经有个案例，运维在hosts里加了一行0.0.1 www.example.com做测试，后来忘了删，导致生产环境一直“解析”到本机地址,排查了半天DNS才发现问题。
cat /etc/hosts
看到有异常条目时,直接注释掉就是最快解法。
CentOS7域名解析失败常见问题解答
问：CentOS7域名解析失败，ping IP能通但ping域名不通，最可能是什么原因？
答：DNS服务器配置错误或DNS服务不可达，先用cat /etc/resolv.conf检查nameserver地址，再用nslookup 域名 223.5.5.5验证备用DNS是否可解析，若备用DNS能解析,则替换原DNS服务器地址即可。
问：resolv.conf每次重启都会被重置，怎么锁定DNS配置？
答：停止NetworkManager对resolv.conf的管理，在网卡配置文件/etc/sysconfig/network-scripts/ifcfg-eth0中设置PEERDNS=no和DNS1=223.5.5.5，然后执行systemctl restart network，如果系统使用systemd-resolved，还需要systemctl disable systemd-resolved并重新生成/etc/resolv.conf的软链接。
问：局域网内CentOS7无法解析域名，其他机器正常，问题出在哪里？
答：多半是这台机器的resolv.conf配置与局域网内其他机器不一致，或者网关出方向对53端口做了限制，对比正常机器的resolv.conf内容，确认网段内网关配置一致，再用tcpdump -i eth0 port 53抓包确认DNS请求是否发出、是否有响应返回。
说到底，CentOS7域名解析失败的核心就是一句话：配置文件写对，网络链路通，防火墙放行，按照上面的思路逐层验证，多数问题都能在几分钟内解决，记住DNS排查的黄金顺序先看resolv.conf，再验nslookup，最后查路由和防火墙这就是最快的路径。