1. 问题现象与初步诊断
最近在Ubuntu 20.04服务器上配置静态IP和DNS后，遇到了一个典型的网络问题：域名解析失败。执行ping baidu.com时，系统返回"Temporary failure in name resolution"错误。这个报错表面看是DNS解析问题，但背后可能隐藏着多种可能性。
1.1 基础环境确认
首先需要确认的是网络基础配置是否正常。通过ip a命令查看网卡状态，确认ens33网卡已正确获取配置的静态IP（192.168.30.101）。接着用ping 192.168.30.2测试网关连通性，这一步很关键，因为即使DNS配置正确，如果网关不通，所有外部请求都会失败。
注意：在排查网络问题时，一定要遵循从底层到高层的顺序：物理连接→IP连通性→DNS解析。这个顺序能帮你快速定位问题所在层级。
1.2 DNS服务测试
当确认IP层通信正常后，下一步就是测试DNS解析。除了常用的ping命令，更专业的做法是使用nslookup或dig工具：
bash复制nslookup baidu.com 223.5.5.5
dig @223.5.5.5 baidu.com
这两个命令能直接向指定DNS服务器发起查询，避免了系统缓存等因素的干扰。如果这些命令也失败，就基本可以确定是DNS服务器访问性问题。
2. 深入排查：宿主机网络环境分析
2.1 宿主机DNS可达性测试
在虚拟化环境中，虚拟机的网络依赖于宿主机的物理网络。因此当虚拟机出现网络问题时，宿主机环境是需要排查的重点。在Windows宿主机上执行以下测试：
cmd复制ping 223.5.5.5
nslookup www.baidu.com 223.5.5.5
测试结果显示宿主机完全无法访问223.5.5.5这个DNS服务器。这就是问题的根源所在——虚拟机配置的DNS服务器在宿主机层面就已经不可达。
2.2 网络限制可能性分析
企业网络或校园网常常会对DNS访问进行限制，可能的原因包括：
- 防火墙阻止了对特定DNS的访问
- 网络策略强制使用内部DNS服务器
- ISP对公共DNS进行了屏蔽
遇到这种情况，可以先尝试使用网络管理员提供的官方DNS，或者测试其他公共DNS服务器的可达性。
3. 解决方案：DNS服务器选型与配置
3.1 国内主流公共DNS推荐
经过测试，以下DNS服务器在国内环境中表现稳定：
| DNS提供商 | 主DNS | 备用DNS | 特点 |
|---|---|---|---|
| 阿里云 | 223.5.5.5 | 223.6.6.6 | 响应快，支持EDNS |
| 腾讯 | 119.29.29.29 | - | 腾讯生态优化 |
| 114DNS | 114.114.114.114 | 114.114.115.115 | 覆盖广，稳定性高 |
| 百度 | 180.76.76.76 | - | 百度服务优化 |
3.2 Netplan多DNS配置实践
Ubuntu从17.10开始使用Netplan作为网络配置工具。以下是经过验证的可靠配置：
yaml复制network:
version: 2
renderer: networkd
ethernets:
ens33:
addresses:
- 192.168.30.101/24
routes:
- to: default
via: 192.168.30.2
nameservers:
addresses:
- 223.6.6.6 # 阿里云备用
- 114.114.114.114 # 114DNS
- 119.29.29.29 # 腾讯DNS
- 8.8.8.8 # Google DNS(备用)
配置完成后，必须执行sudo netplan apply使配置生效。为了确保配置正确加载，可以检查systemd-resolved服务的状态：
bash复制systemctl status systemd-resolved
3.3 DNS配置验证技巧
配置完成后，建议通过以下方式验证：
- 查看实际的DNS服务器使用情况：
bash复制systemd-resolve --status
- 测试不同DNS服务器的响应时间：
bash复制time dig @223.6.6.6 baidu.com
time dig @114.114.114.114 baidu.com
- 检查DNS缓存记录：
bash复制systemd-resolve --statistics
4. 高级排查与优化技巧
4.1 systemd-resolved服务深入
Ubuntu使用systemd-resolved管理DNS解析，了解其工作原理对排查问题很有帮助：
- 配置文件：/etc/systemd/resolved.conf
- 缓存位置：/run/systemd/resolve/resolv.conf
- 查看完整解析流程：
journalctl -u systemd-resolved -f
4.2 多DNS的故障转移机制
当配置多个DNS服务器时，Linux系统默认会按顺序尝试，超时时间为5秒。可以通过修改resolved.conf调整：
ini复制[Resolve]
DNS=223.6.6.6 114.114.114.114
FallbackDNS=8.8.8.8 1.1.1.1
DNSOverTLS=opportunistic
4.3 企业环境特殊考量
在企业网络中，可能还需要考虑：
- 内部域名解析：需要在search域中添加公司内部域名
- DNS安全：考虑使用DNS-over-TLS加密查询
- 分区域解析：不同网络区域使用不同的DNS策略
5. 常见问题与解决方案
5.1 DNS解析时好时坏
可能原因：
- 网络抖动导致DNS查询超时
- DNS服务器负载不均衡
- 本地缓存问题
解决方案：
bash复制# 清空DNS缓存
sudo systemd-resolve --flush-caches
# 设置更短的重试时间
sudo mkdir -p /etc/systemd/resolved.conf.d
echo -e "[Resolve]\nDNS=223.6.6.6\nDNSOverTLS=opportunistic" | sudo tee /etc/systemd/resolved.conf.d/99-fallback.conf
sudo systemctl restart systemd-resolved
5.2 特定域名无法解析
排查步骤：
- 检查域名是否被污染：
dig +trace 域名 - 测试不同DNS服务器的解析结果差异
- 检查本地hosts文件是否被修改
5.3 虚拟机与宿主机DNS差异
在虚拟化环境中，建议：
- 宿主机和虚拟机使用相同的DNS服务器
- 检查虚拟网络配置（NAT/桥接模式）
- 禁用虚拟网卡的IPv6功能测试
6. 网络诊断工具箱
以下命令在排查网络问题时非常有用：
- 基础连通性测试：
bash复制ping -c 4 114.114.114.114
traceroute 114.114.114.114
mtr -rw 114.114.114.114
- DNS专用工具：
bash复制dig +short myip.opendns.com @resolver1.opendns.com # 获取公网IP
dig +trace baidu.com # 完整解析过程
dnstracer -s . baidu.com # DNS路径追踪
- 高级分析：
bash复制tcpdump -i ens33 port 53 -w dns.pcap # 抓取DNS流量
ss -tulnp | grep 53 # 查看本地DNS服务
在实际工作中，我习惯将常用的诊断命令保存为脚本，遇到网络问题时一键运行收集信息。例如创建一个network_check.sh：
bash复制#!/bin/bash
echo "=== 网络接口状态 ==="
ip a
echo "\n=== 路由表 ==="
ip route
echo "\n=== DNS配置 ==="
systemd-resolve --status
echo "\n=== 到DNS的连通性 ==="
ping -c 2 223.6.6.6
echo "\n=== DNS解析测试 ==="
dig +short baidu.com @223.6.6.6
这个脚本能快速给出网络状态的全貌，大大提高了排查效率。