服务器DNS出问题，大多数时候不是“坏了”，而是配置、缓存、解析链路某个环节卡住了，按照“先查配置、再测链路、后换方案”的顺序排查，多数问题半小时内能定位。
先分清是配置问题还是解析问题
DNS故障最迷惑人的一点在于：现象看起来一样，根源可能完全不同，操作前先做一个快速分流判断,能省下大量无效操作时间。
在服务器上执行三个命令,基本能确定问题范围：
ping 服务器公网IP：判断网络链路是否存活nslookup 你的域名：判断DNS解析是否正常curl -I http://你的域名：判断业务服务是否响应
如果ping IP通但nslookup报错，问题出在DNS解析环节，如果nslookup正常但curl超时，问题在后端服务或防火墙，如果ping IP都不通，那是网络层故障，跟DNS没关系,先去联系机房或云服务商。
多数情况下，DNS故障表现为“能连IP但解析不了域名”或“解析超时”，这两种场景的排查路径差异很大,下面逐一拆解。
服务器dns解析失败怎么修复：从这三步入手
第一步：确认resolv.conf是否被覆盖
在Linux服务器上执行：
cat /etc/resolv.conf检查nameserver字段是否指向正确的DNS服务器，这里有一个极易踩的坑：多数云服务器或使用了NetworkManager、systemd-resolved的系统，会在重启或网络变更时自动重写这个文件，你以为改好了,重启后又被覆盖回默认值。
如果发现nameserver不是你设置的地址，不要急着改文件本身,先找出是谁在覆盖它：
systemctl status systemd-resolved
systemctl status NetworkManager行业共识认为，这类“改了又被还原”的问题，在Ubuntu 18.04+、CentOS 8+、Debian 10+的默认安装中相当常见，正确做法是按住底层服务，如果使用systemd-resolved，修改/etc/systemd/resolved.conf中的DNS=字段，然后执行systemctl restart systemd-resolved，同时把/etc/resolv.conf软链接到/run/systemd/resolve/resolv.conf,保证配置来源统一。
第二步：用dig命令定位解析链路卡点
配置确认无误后，用dig逐层排查：
dig @8.8.8.8 example.com
dig @114.114.114.114 example.com
dig example.com第一个命令指定谷歌DNS解析，第二个指定国内公共DNS，第三个走服务器当前配置的DNS，对比三个结果中的Query time和status字段：
- 如果指定公共DNS解析正常、走本地DNS超时，说明本地DNS服务器或到本地DNS的链路有问题
- 如果所有外部DNS都能解析、只有服务器配置的DNS不行，问题几乎锁定在服务器自身的配置或所在网络环境
继续加一个追踪参数：
dig +trace example.com+trace能看到从根域到权威域服务器的完整解析路径，哪一步卡住不返回，问题就出在那一级，多数情况下，卡在“本地递归DNS”这一层最常见。
第三步：测试UDP/TCP 53端口连通性
DNS默认走UDP 53端口，但数据量较大时会切换TCP 53，很多防火墙规则只放行了UDP却拦了TCP,导致大流量解析请求直接超时。
用以下命令验证：
nc -vz -u 8.8.8.8 53
nc -vz 8.8.8.8 53如果UDP通而TCP不通，在防火墙中补充放行TCP 53端口，这个细节在云服务器安全组策略里尤其容易被忽略某些云厂商的默认安全组只放行80、443、22，需要手动添加53端口的入站规则,包括UDP和TCP两个协议。
服务器dns一直出现问题怎么办：治本方案
如果服务器DNS问题反复出现，每次修完过段时间又犯，说明治标的路已经走不通了，此时需要从架构层面做加固，核心思路是“去掉单点、增加缓存、自动容错”。
配置systemd-resolved防止配置漂移
在Ubuntu 22.04、Debian 12等新版系统上，systemd-resolved是默认的DNS解析服务，直接改/etc/resolv.conf必然被重置,正确姿势是：
sudo systemctl enable --now systemd-resolved
sudo nano /etc/systemd/resolved.conf在[Resolve]段落下配置：
DNS=223.5.5.5 119.29.29.29
FallbackDNS=8.8.8.8 1.1.1.1
DNSSEC=allow-downgrade
Cache=yes配置完成后，systemctl restart systemd-resolved，这里的思路是同时配置主DNS和备用DNS，并开启本地缓存，单一DNS服务商出现故障时，系统能自动切换，不会出现“整个服务器断网”的错觉。
使用dnsmasq做本地DNS缓存代理
对于频繁请求外部域名的业务服务器，直接在本地跑一个dnsmasq缓存代理,能显著降低对外部DNS的依赖：
apt install dnsmasq
nano /etc/dnsmasq.conf关键配置项：
resolv-file=/etc/resolv.dnsmasq.conf
cache-size=10000
no-resolv
server=223.5.5.5
server=119.29.29.29
server=8.8.8.8把上游DNS写到/etc/resolv.dnsmasq.conf，服务器自身的/etc/resolv.conf只指向0.0.1，这样一来，所有DNS请求先在本地缓存中查找，命中就直接返回，不依赖外网，即使上游DNS全部故障,已缓存过的域名解析依然可用。
添加解析状态自动监控
DNS故障往往不是突发的，而是有征兆的解析延迟逐渐升高、偶发超时、特定地区解析失败，手动盯不现实,加一个简单的定时监控脚本：
/5 dig @127.0.0.1 example.com +short > /dev/null || echo "DNS异常" | mail -s "DNS告警" admin@example.com这个cron任务每5分钟执行一次解析，失败就发告警邮件，更完整的方案可以用Prometheus的blackbox_exporter做DNS探测，再配合Grafana面板可视化，核心价值在于：出现问题第一分钟就收到通知，而不是等用户反馈说“网站打不开了”才知道。
服务器dns不稳定如何排查外部因素
排除服务器自身配置问题后，外部环境因素同样会导致解析不稳定，这类问题隐蔽性强,排查起来需要换一个思路。
对比主流公共DNS的可用性
国内可用的公共DNS各有侧重,选型时结合自己服务器的地域和用户群体来定：
| DNS服务商 | 首选地址 | 特点 | 适用场景 |
|---|---|---|---|
| 阿里DNS | 5.5.5 | 国内节点覆盖广，解析快 | 面向国内用户的业务 |
| 腾讯DNSPod | 29.29.29 | 抗污染能力强 | 域名在DNSPod托管的场景 |
| 114DNS | 114.114.114 | 老牌，稳定性好 | 通用型备用方案 |
| 谷歌DNS | 8.8.8 | 全球节点多 | 海外服务器、跨境业务 |
| Cloudflare | 1.1.1 | 隐私性好，速度波动大 | 面向海外用户的辅助方案 |
如果你不确定该选哪个,做一次实际测速再决定：
dig @223.5.5.5 example.com | grep "Query time"
dig @119.29.29.29 example.com | grep "Query time"
dig @114.114.114.114 example.com | grep "Query time"连续执行多次，取平均耗时，注意，单次测速没有参考意义，DNS解析受网络波动影响很大,至少测10次以上再看趋势。
检查上游链路的丢包情况
有时候DNS本身没问题，但服务器到DNS服务商之间的网络链路存在丢包，导致解析请求“发出去没回应”或“回应丢失”，用mtr工具查看完整链路：
mtr -rw 223.5.5.5mtr的输出中关注Loss%列，中间某一跳出现丢包不一定影响最终结果（有些路由节点对ICMP不做回应），但如果最后一跳（即目标DNS服务器）的丢包率较高，说明到DNS服务商的链路确实不稳定，此时更换DNS服务商,比自己排查路由链路更高效。
交叉验证解析结果是否被污染
服务器解析到错误的IP、或者解析结果在不同地区不一致，这种情况在中国大陆访问被墙域名时常出现,但在常规业务服务器上也不少见。
判断方法很简单：
dig @8.8.8.8 你的域名
dig @223.5.5.5 你的域名对比两个结果返回的IP是否一致，如果不一致，参考以下思路处理：确认域名解析在云解析平台上的配置是否正常，检查是否有多个解析记录互相冲突,联系域名注册商核实DNS服务器状态。
判断为DNS污染后，解法是在权威侧配置DNSSEC，一定程度上能抵御域名劫持，国内公共DNS普遍支持DNSSEC验证,配置时在解析平台开启即可。
关于服务器DNS故障的常见问答
服务器能ping通IP但域名解析不了，问题出在哪？
先确认这个“解析不了”是只针对特定域名还是所有域名，针对所有域名，大概率是服务器配置的DNS服务器不可达或已失效，换成公共DNS如5.5.5、29.29.29再试，只针对特定域名，可能该域名的NS记录指向的权威DNS故障或配置有误，用dig 该域名 NS查询并逐级检查权威服务器是否正常响应。
修改了resolv.conf之后重启就失效，怎么处理？
这是新版Linux系统的正常行为，说明systemd-resolved或NetworkManager在接管网络配置，不要在/etc/resolv.conf里硬改，而是通过systemd-resolved的配置文件或NetworkManager的DNS设置来修改，DNS配置“漂移”地更频繁的服务器，建议直接部署dnsmasq或unbound作为本地递归解析器,彻底绕过被覆盖的问题。
服务器解析速度慢，如何确认是DNS的问题？
在服务器上执行dig 你的域名查看Query time字段，数值超过100ms说明解析链路偏慢，再用dig @8.8.8.8 你的域名对比，如果外部DNS解析速度正常，说明本地DNS递归能力不足或网络链路到DNS服务商有延迟，用dig +trace 你的域名可以看到每一级解析的耗时，耗时最长的哪一级就是瓶颈所在，多数情况下，把服务器默认DNS换成延迟最低的公共DNS,解析慢的问题能直接解决。
DNS问题解决的核心原则就一条：把服务器自身的配置和外部链路分开看待，配置问题花5分钟排查，链路问题换一个DNS服务商做交叉测试，比反复重启网络服务有效得多，无论是配置漂移、53端口受限还是解析链路劣化，按上面的步骤逐层排查总能找到答案，服务器DNS稳定了,业务的可用性就稳了一半。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/600197.html
