Linux域名解析失败怎么办？DNS配置排查方法

Linux域名解析失败，先查/etc/resolv.conf里的nameserver是否可达，再用dig或nslookup分层验证，多数问题出在DNS配置、53端口被挡或解析服务被覆盖。
别急着重装系统，按网络层、DNS配置、解析服务、持久化四步走，通常十分钟内能缩小范围。

Linux域名解析失败怎么排查？先分清DNS还是网络问题

第一步：用ping和dig把问题切开

应用日志里冒出UnknownHostException，浏览器打不开网页，但SSH还连着服务器，此时先别改配置,先做两个动作：

• ping -c 3 223.5.5.5：测试到公网IP是否通。
• ping -c 3 www.baidu.com：测试域名解析是否通。
• dig @223.5.5.5 www.baidu.com +short：绕过系统DNS,直接问指定服务器。
• nslookup www.baidu.com 114.114.114.114：换一个DNS验证。
• getent hosts www.baidu.com：走Linux NSS解析链,更接近应用真实行为。

如果IP能通、域名不通，问题大概率在DNS，如果IP也不通，先查路由、网卡、安全组和上游网络。

第二步：检查DNS服务器连通性和53端口

DNS主要走UDP/TCP 53，云服务器安全组、本机防火墙、上游ACL都可能挡住。

• nc -zvu 223.5.5.5 53 或 dig @223.5.5.5 www.baidu.com。
• ss -lunp | grep :53 查看本机是否监听53。
• iptables -L -n -v、firewall-cmd --list-all 查看防火墙规则。
• 云控制台检查安全组出站规则，确认UDP/TCP 53未限制。
• tcpdump -i any port 53 -nn 抓包，看请求有没有发出、有没有响应。

如果dig @公共DNS

正常，但直接dig 域名超时,说明系统默认DNS指向了不可达地址。

第三步：看解析顺序和hosts文件

行业共识认为，Linux解析顺序由/etc/nsswitch.conf和/etc/resolv.conf共同决定。

• cat /etc/nsswitch.conf，确认hosts: files dns顺序正常。
• cat /etc/hosts,检查是否误写了错误IP。
• ls -l /etc/resolv.conf,看它是不是符号链接。
• cat /etc/resolv.conf，确认nameserver、search、options。
• systemd-resolve --status或resolvectl status,查看实际生效DNS。

云服务器Linux域名解析失败？优先检查resolv.conf和systemd-resolved

/etc/resolv.conf该写什么

临时排障可以这样写：

nameserver 223.5.5.5
nameserver 114.114.114.114
options timeout:1 attempts:2

timeout:1 attempts:2能减少应用等待时间，生产环境不要长期只靠手改，因为重启、DHCP续租、NetworkManager都可能覆盖它。

systemd-resolved和NetworkManager谁在管DNS

不同发行版和镜像差异很大,先看服务状态：

• systemctl status systemd-resolved
• systemctl status NetworkManager
• resolvectl status
• nmcli dev show | grep DNS

如果/etc/resolv.conf指向/run/systemd/resolve/stub-resolv.conf，应改/etc/systemd/resolved.conf：

[Resolve]
DNS=223.5.5.5 114.114.114.114
FallbackDNS=119.29.29.29

然后执行：

systemctl restart systemd-resolved
resolvectl flush-caches

如果由NetworkManager管理,使用：

nmcli con mod "连接名" ipv4.dns "223.5.5.5 114.114.114.114"
nmcli con up "连接名"

容器与Kubernetes场景

Docker容器里/etc/resolv.conf可能显示0.0.11，这是Docker内嵌DNS,Kubernetes里则常走CoreDNS。

• docker exec -it 容器名 cat /etc/resolv.conf
• kubectl get pods -n kube-system
• kubectl exec -it 业务Pod -- nslookup kubernetes.default
• 检查CoreDNS日志和ConfigMap。

宿主机DNS异常会传导到容器，先修宿主机,再查容器网络。

Linux DNS解析失败和网络不通有什么区别？对比排查更省时间

表现对比

常见误判

• 能解析但连接超时，可能是应用端口、负载均衡或后端服务问题。
• DNS慢导致超时，dig结果里的Query time会明显偏高。
• IPv6的AAAA记录异常时，应用可能优先走IPv6并失败，可用dig AAAA 域名验证。
• /etc/hosts写错后，dig正常但应用仍解析到旧IP。

北京机房Linux域名解析失败怎么办？地域DNS与运营商线路

北京机房、华北地域云服务器出现解析失败时，先确认内网DNS是否可达，云厂商VPC通常提供内网DNS，地址会在控制台、DHCP选项或/etc/resolv.conf里体现。

• dig @内网DNS地址 内网域名,验证内网解析。
• 检查VPC DNS、PrivateZone、内网域名关联关系。
• 跨地域访问时,确认路由和对等连接是否放行53端口。
• 北京联通、电信、移动线路差异可能影响递归DNS质量,临时切公共DNS可快速判断。
• 如果只有内网域名失败，优先查内网DNS和搜索域search配置。

据工信部公开信息，域名系统属于互联网关键基础设施，地域线路问题往往表现为部分域名解析慢,而不是全部失败。

免费DNS和付费DNS在Linux解析失败时怎么选？价格与场景

免费公共DNS适合排障和临时切换，付费DNS通常提供SLA、Anycast、解析日志和防劫持能力，适合生产业务,但解析失败未必靠升级付费DNS解决。

企业内网更常用BIND、Unbound、CoreDNS自建递归或转发，业内专家指出，DNS排障应先确认网络层可达，再看解析配置,最后才考虑更换DNS服务商。

修复后如何验证和防止复发

验证命令

• dig +short 域名
• getent hosts 域名
• resolvectl query 域名
• curl -v https://域名
• ping -c 3 域名

持久化修改

不要只改/etc/resolv.conf，根据系统实际管理方式，写入systemd-resolved、NetworkManager或dhclient.conf，有人用chattr +i锁定文件，但网络切换后可能导致DNS失效,不建议作为长期方案。

日志与监控

• journalctl -u systemd-resolved -u NetworkManager --since "10 min ago"
• journalctl -u NetworkManager --since "10 min ago"
• tcpdump -i any port 53 -nn
• 应用侧关注UnknownHostException、Name or service not known。
• 监控DNS查询延迟、失败率和53端口可用性。

Linux域名解析失败常见问题Q&A

Q1：Linux域名解析失败但ping IP正常，问题一定在DNS吗？

多数情况下是DNS，但也要查/etc/nsswitch.conf、/etc/hosts和IPv6。getent hosts能验证NSS解析链，比单独dig更接近应用行为。

Q2：修改/etc/resolv.conf后重启又恢复怎么办？

该文件常由NetworkManager或systemd-resolved动态生成，应在对应配置中写DNS，而不是只改文件本身，检查ls -l /etc/resolv.conf和resolvectl status即可确认。

Q3：Linux域名解析失败怎么快速恢复业务？

先临时在/etc/resolv.conf加可用nameserver，并执行resolvectl flush-caches；同时用dig @IP确认DNS可达，检查安全组UDP/TCP 53，临时写入可用nameserver只能缓解当前故障,持久化配置和53端口检查才是恢复后必须完成的操作。

Linux域名解析失败并不神秘，按链路、配置、解析服务、持久化四层查，基本都能定位，先让dig @IP跑通,再解决为什么系统默认DNS走不通。