ubuntu域名故障排查 - 问答

Ubuntu 域名解析故障排查手册

一快速判断与定位

先看是否为网络连通性问题：ping 一个公网 IP（如 8.8.8.8）。若能通而域名不通，基本可判定为 DNS 解析问题；若 IP 也不通，优先排查网络链路、路由、网关与防火墙。
直接测试域名解析：使用 nslookup 或 dig 指定公共 DNS 验证，例如：nslookup www.baidu.com 8.8.8.8；若指定 DNS 可解析，说明本地 DNS 配置或上游 DNS 异常。
检查本地解析链路：确认 /etc/nsswitch.conf 中 hosts 行包含 dns（如：hosts: files dns [myhostname]），否则系统不会走 DNS 查询。
若使用 systemd-resolved（常见现象是 /etc/resolv.conf 指向 127.0.0.53），先清理缓存：sudo systemd-resolve --flush-caches 或重启服务 sudo systemctl restart systemd-resolved。
检查本机防火墙与云上安全组是否放行 UDP/TCP 53 出站（DNS），以及是否误拦截 ICMP（会影响 ping 测试结论）。

二常见根因与修复要点

/etc/resolv.conf 被覆盖或配置错误：看到 127.0.0.53 表示使用 systemd-resolved；若看到错误/空的 nameserver，可临时写入公共 DNS（如 8.8.8.8、114.114.114.114），但需按所用网络管理方式做持久化。
持久化 DNS 配置：
- 使用 Netplan（Ubuntu 18.04+ 常见）：编辑 /etc/netplan/*.yaml，在相应网卡或全局添加 nameservers.addresses，然后执行 sudo netplan apply。
- 使用 NetworkManager：在其配置或 nmcli 中设置 DNS；如使用 resolved，也可在 /etc/systemd/resolved.conf 中设置 DNS 并重启服务。
仅个别域名失败：可能为 DNS 污染/劫持或上游故障，优先更换为更稳定的公共 DNS（如 1.1.1.1、8.8.8.8）并复测。
解析慢或间歇性失败：更换响应更快、更稳定的 DNS；必要时对比不同网络环境（蜂窝/宽带/公司内网）定位是否为上游问题。
虚拟机/特定网络环境异常：某些环境下 systemd-resolved 与网络栈配合不佳，可临时停用 resolved 并手动管理 /etc/resolv.conf（见下文“应急方案”）。

三建议的排查顺序与命令清单

连通性：ping -c 4 8.8.8.8
直接解析：nslookup www.baidu.com 8.8.8.8；对比 dig +short www.baidu.com @8.8.8.8
查看当前 DNS：cat /etc/resolv.conf；若指向 127.0.0.53，说明使用 systemd-resolved
清缓存：sudo systemd-resolve --flush-caches 或 sudo systemctl restart systemd-resolved
检查解析链路：cat /etc/nsswitch.conf | grep hosts（需含 dns）
持久化配置：
- Netplan：编辑 /etc/netplan/*.yaml → sudo netplan apply
- resolved：编辑 /etc/systemd/resolved.conf → sudo systemctl restart systemd-resolved
防火墙/安全组：sudo ufw status；云上安全组放行 UDP/TCP 53 出站
深入抓包：sudo tcpdump -i eth0 port 53（区分请求是否发出、是否收到响应）

四应急方案与注意事项

应急绕过 systemd-resolved：
- 停止并禁用服务：sudo systemctl disable --now systemd-resolved
- 重建 resolv.conf：sudo rm /etc/resolv.conf && echo -e “nameserver 8.8.8.8\nnameserver 114.114.114.114” | sudo tee /etc/resolv.conf
- 防被覆盖：sudo chattr +i /etc/resolv.conf（变更前请评估对系统管理的影响）
风险提示：直接改写或锁定 /etc/resolv.conf 可能与 NetworkManager/Netplan 的管理策略冲突，建议优先使用各自的配置机制进行持久化；应急改动后应在问题解决后恢复为受管配置。

0 赞

0 踩