Ubuntu Server 20.04 重启后DNS失效的根治方案深入解析systemd-resolved服务机制每次重启Ubuntu Server 20.04后都要手动修复DNS解析这种反复出现的Temporary failure in name resolution错误确实令人抓狂。作为长期维护Linux服务器的运维人员我完全理解这种挫败感——明明配置了正确的DNS服务器重启后却总是需要手动干预才能恢复正常。本文将彻底剖析这个问题的根源并提供几种一劳永逸的解决方案。这个问题特别容易出现在开发测试环境、频繁重启的实验室服务器或者使用云平台模板快速部署的Ubuntu实例上。表面看是DNS解析失败实则反映了systemd-resolved服务在系统启动流程中的特殊行为机制。与网上常见的临时修复方案不同我们将直击问题本质确保DNS服务在每次重启后都能自动恢复工作。1. 问题现象与初步诊断当你在Ubuntu Server 20.04上遇到DNS解析问题时通常会看到这样的症状$ ping qq.com ping: qq.com: Temporary failure in name resolution但直接ping IP地址却能成功$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq1 ttl117 time8.43 ms这种表现明确指向了DNS解析问题而非网络连接问题。执行以下命令可以快速确认当前DNS状态$ resolvectl status Global Protocols: -LLMNR -mDNS -DNSOverTLS resolv.conf mode: foreign一个关键线索是手动重启systemd-resolved服务后问题立即解决$ sudo systemctl restart systemd-resolved $ ping qq.com # 现在应该能正常解析了这表明我们的DNS配置本身是正确的只是服务没有在系统启动时自动运行。接下来我们需要深入理解systemd-resolved的工作原理。2. systemd-resolved服务机制解析Ubuntu 20.04默认使用systemd-resolved作为DNS解析管理器这是一个设计上的重大变化。传统Linux系统中/etc/resolv.conf是静态配置文件而在新版本中它变成了一个由systemd-resolved管理的符号链接$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 39 Feb 15 2020 /etc/resolv.conf - ../run/systemd/resolve/stub-resolv.conf这种设计带来了几个重要影响动态管理resolv.conf内容由systemd-resolved动态生成手动编辑会被覆盖多源整合可以从NetworkManager、netplan等多个配置源合并DNS设置缓存加速内置DNS缓存提高解析速度服务启动流程中的常见问题包括阶段可能的问题表现启动时服务依赖未满足DNS不工作运行中配置冲突部分域名解析失败重启后服务未自动启动需要手动干预3. 永久解决方案确保服务开机自启3.1 方法一直接启用systemd-resolved服务最直接的解决方案是确保systemd-resolved服务在启动时自动运行$ sudo systemctl enable --now systemd-resolved这个命令做了两件事enable设置服务为开机自启--now立即启动服务不需要重启验证服务状态$ systemctl is-enabled systemd-resolved enabled $ systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-03-16 10:23:45 UTC; 5min ago3.2 方法二通过netplan配置持久化DNS对于使用netplan的网络配置可以在YAML文件中指定DNS服务器network: version: 2 ethernets: eth0: dhcp4: true nameservers: addresses: [8.8.8.8, 1.1.1.1]应用配置$ sudo netplan applynetplan会自动将这些设置传递给systemd-resolved并确保服务正确启动。3.3 方法三修改resolved.conf配置文件编辑/etc/systemd/resolved.conf确保有正确的全局DNS设置[Resolve] DNS8.8.8.8 1.1.1.1 FallbackDNS9.9.9.9 Domains~.然后重新加载配置$ sudo systemctl restart systemd-resolved $ sudo systemctl restart systemd-networkd4. 高级排查与疑难解答如果上述方法仍不能解决问题可以尝试以下高级排查步骤检查服务依赖关系$ systemctl list-dependencies systemd-resolved查看详细的启动日志$ journalctl -u systemd-resolved -b检查网络接口的DNS配置$ networkctl status常见问题解决方案对照表问题现象可能原因解决方案重启后DNS失效服务未启用systemctl enable systemd-resolved部分域名解析失败配置冲突检查netplan和resolved.conf解析延迟大缓存问题systemd-resolved flush-caches服务无法启动端口冲突检查53端口占用情况5. 最佳实践与经验分享在管理多台Ubuntu服务器的过程中我总结了以下可靠的工作流程初始化设置sudo apt update sudo apt install resolvconf # 可选提供传统兼容性 sudo systemctl enable --now systemd-resolved网络配置优先使用netplan进行DNS设置避免手动修改/etc/resolv.conf对于复杂环境考虑使用DNSMasq作为本地缓存验证步骤dig example.com short # 验证解析 systemd-resolve --status # 查看当前配置 ping -c 3 example.com # 测试连通性一个特别容易忽视的细节是在云环境如AWS、Azure中某些云平台会覆盖DNS设置。这时需要在cloud-init配置中禁用这个行为# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg network: {config: disabled}经过这些年的运维实践我发现Ubuntu Server 20.04的DNS问题大多源于对systemd-resolved服务机制的理解不足。与其每次重启后手动修复不如花点时间彻底理解并正确配置这套新机制。记住关键一点在现代Ubuntu系统中直接操作/etc/resolv.conf的时代已经过去了拥抱systemd-resolved才是王道。