Linux重启后DNS配置丢失，如何设置才能永久生效不被覆盖？

在Linux操作系统中，DNS（域名系统）扮演着互联网“电话簿”的角色，负责将我们易于记忆的域名（如www.google.com）解析为机器能够识别的IP地址（如142.250.199.68），当DNS配置丢失或出现问题时，最直观的现象便是：可以ping通公网IP地址，但无法访问任何域名，浏览器提示“无法解析服务器名称”，这会给日常使用和服务器管理带来极大困扰，本文将深入探讨Linux下DNS丢失的常见原因、系统化的排查步骤以及多种有效的解决方案。

DNS丢失的常见根源

Linux系统DNS配置的丢失并非单一原因造成，通常与系统网络管理机制、服务状态或人为操作有关。

1. 网络管理器的自动覆盖：现代Linux发行版（如Ubuntu 20.04+, CentOS 8+）普遍使用NetworkManager和systemd-resolved来协同管理网络配置。/etc/resolv.conf文件，这个传统上用于存放DNS服务器地址的文件，现在常常只是一个指向systemd-resolved管理下的存根文件（如/run/systemd/resolve/stub-resolv.conf）的符号链接，当网络环境变化（如重启、切换Wi-Fi）时，NetworkManager会通过DHCP获取新的DNS信息，并重写这个由systemd-resolved管理的内部文件，导致用户手动在/etc/resolv.conf中的修改被覆盖。

2. DHCP客户端的强制更新：在动态IP环境下，DHCP客户端（如dhclient）在续租IP地址时，会从DHCP服务器获取包括DNS在内的网络配置信息，并默认用它来更新/etc/resolv.conf,这同样会覆盖任何静态配置。

3. DNS解析服务异常：systemd-resolved服务本身可能因为配置错误、资源耗尽或程序bug而停止工作或行为异常，即使/etc/resolv.conf内容正确，负责处理查询请求的后台服务“掉链子”,也会导致解析失败。

4. 防火墙或安全策略拦截：系统或网络层面的防火墙（如ufw, firewalld）可能会错误地阻止DNS查询所使用的UDP/TCP 53端口,导致请求无法发送到DNS服务器。

系统化排查步骤

面对DNS丢失问题，应遵循由表及里、由简到繁的原则进行排查。

第一步：确认问题根源
通过ping命令进行诊断。

# 测试IP连通性（正常）
ping 8.8.8.8
# 测试域名解析（失败）
ping www.baidu.com

如果IP通而域名不通，基本可以锁定是DNS问题，使用更专业的查询工具nslookup或dig。

nslookup www.baidu.com

如果命令返回“server can’t find”或“connection timed out”等错误,则进一步证实了DNS解析故障。

第二步：检查核心配置文件
查看/etc/resolv.conf。

cat /etc/resolv.conf
```是否为空，或者是否包含不正确的nameserver，注意文件开头是否有注释，提示它被某个程序管理，使用`ls -lh /etc/resolv.conf`查看它是否为符号链接，以及链接的真实目标。
**第三步：检查DNS解析服务状态**
对于使用`systemd-resolved`的系统，检查其运行状态至关重要。
```bash
systemctl status systemd-resolved

如果服务未运行（inactive/dead），尝试启动它：sudo systemctl start systemd-resolved并设置开机自启，如果服务正在运行但仍有问题，可以查看其日志：journalctl -u systemd-resolved -f,寻找可能的错误线索。

第四步：检查防火墙规则
确认本地防火墙没有拦截DNS流量。

# 对于ufw
sudo ufw status
# 对于firewalld
sudo firewall-cmd --list-all

检查是否有规则拒绝53端口的通信。

持久化解决方案

临时修改/etc/resolv.conf治标不治本,需要采用与系统网络管理机制相兼容的持久化方案。

推荐操作：最优雅、最符合现代Linux设计哲学的方法是配置systemd-resolved，编辑/etc/systemd/resolved.conf如下：

[Resolve]
DNS=8.8.8.8 1.1.1.1
#FallbackDNS=...
#Domains=
LLMNR=no
#MulticastDNS=no
DNSSEC=no
Cache=yes
DNSStubListener=yes

保存后，执行sudo systemctl restart systemd-resolved，如果/etc/resolv.conf不是指向/run/systemd/resolve/resolv.conf的链接,可以手动修正：

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

这样，系统既能享受到systemd-resolved带来的缓存和稳定性优势,又能使用我们指定的DNS服务器。

相关问答FAQs

Q1: 为什么我每次手动修改/etc/resolv.conf文件后，重启或网络重连后配置就丢失了？
A: 这是因为您的Linux系统使用了NetworkManager或systemd-resolved等网络管理工具，这些工具会动态管理网络配置，包括DNS。/etc/resolv.conf文件可能是一个由它们管理的符号链接，或者它们被配置为在检测到网络变化时自动覆写该文件，任何直接的手动修改都会被后续的自动操作所取代，正确的做法是通过这些工具自身的配置接口（如nm-connection-editor或编辑/etc/systemd/resolved.conf）来设置DNS,这样才能实现持久化。

Q2: systemd-resolved和传统的dnsmasq在DNS解析上有什么区别？我应该如何选择？
A: systemd-resolved是systemd init系统的一部分，是一个本地化的、系统级的网络名称解析服务，它不仅提供DNS缓存，还能处理LLMNR（本地链路多播名称解析）和MulticastDNS，并统一管理/etc/resolv.conf，它与系统集成度非常高，是现代主流发行版的默认选择。dnsmasq则是一个更轻量级、功能更专注的服务，主要提供DNS缓存和DHCP服务器功能，它非常灵活，常用于路由器、虚拟机的NAT网络或作为独立的本地缓存服务器。选择建议：对于大多数桌面和服务器用户，使用系统默认的systemd-resolved是最简单、最稳定的选择，如果您需要构建一个复杂的网络环境（如为多个虚拟机提供DHCP和DNS），或者需要一个高度可定制的轻量级缓存服务器，那么单独部署dnsmasq会更合适。