Debian系统里，域名解析配置经常让人头疼，特别是resolv.conf和systemd-resolved。很多运维会发现/etc/resolv.conf文件总是被覆盖，或者DNS解析时快时慢、甚至失败。根本原因在于Debian默认的DNS管理机制变了，从传统的静态文件管理转向了systemd-resolved的动态服务。如果你直接修改/etc/resolv.conf，重启网络或者系统后，改动很可能就消失了，因为systemd-resolved或NetworkManager等工具会重新生成这个文件。
理解Debian中DNS配置的演变：从静态文件到动态服务
过去，Debian和其他Linux系统一样，完全依靠/etc/resolv.conf这个静态文件来配置DNS服务器和搜索域。文件内容很简单，就是几行“nameserver 8.8.8.8”这样的配置。但随着系统复杂化，特别是笔记本电脑在不同Wi-Fi网络间切换、VPN连接时，需要动态更新DNS设置。于是，systemd-resolved应运而生，它作为一个系统服务，统一管理所有网络接口的DNS配置，并提供一个稳定的DNS解析接口。
systemd-resolved的核心工作原理与状态查看
systemd-resolved服务运行后，它会监听本地的127.0.0.53这个IP地址，作为系统的DNS存根解析器（stub resolver）。你看到的/etc/resolv.conf通常变成一个指向本地存根解析器的符号链接：
lrwxrwxrwx 1 root root 39 Apr 1 10:00 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
这个文件里通常只有一行“nameserver 127.0.0.53”。所有应用程序的DNS查询都会先发到127.0.0.53，再由systemd-resolved根据它自己的配置决定转发到哪个真正的上游DNS服务器（比如运营商DNS或公共DNS）。要查看其真实配置和状态，请使用命令：
systemd-resolve --status
或
resolvectl status
。这会详细列出每个网络接口（如eth0、wlan0）对应的DNS服务器和搜索域，这些信息来源于NetworkManager或systemd-networkd。
如何正确配置systemd-resolved的上游DNS服务器
不要直接改/etc/resolv.conf。配置systemd-resolved主要有两种方法。第一种是使用resolvectl命令进行运行时配置（重启服务可能失效）：
resolvectl dns eth0 8.8.8.8 1.1.1.1 resolvectl domain eth0 "internal.example.com"
这会将接口eth0的DNS服务器设置为8.8.8.8和1.1.1.1，并设置搜索域。第二种，也是推荐的方法，是修改systemd-resolved的全局配置文件。编辑/etc/systemd/resolved.conf文件：
[Resolve] DNS=8.8.8.8 1.1.1.1 FallbackDNS=9.9.9.9 2620:fe::fe Domains=~example.com DNSSEC=allow-downgrade Cache=yes
修改后，重启服务生效：
systemctl restart systemd-resolved
。这里的DNS是主用服务器，FallbackDNS是备用，Domains配置特定域的搜索行为，“~”表示仅对此域使用指定的DNS。
彻底禁用systemd-resolved并回归传统静态resolv.conf管理
如果你的环境简单，或者某些老旧应用与systemd-resolved兼容性不好，可以选择禁用它，回归传统的静态文件管理。首先，停止并禁用服务：
systemctl stop systemd-resolved systemctl disable systemd-resolved
然后，删除符号链接，创建静态的/etc/resolv.conf文件：
rm -f /etc/resolv.conf cat > /etc/resolv.conf << EOF nameserver 114.114.114.114 nameserver 8.8.8.8 search localdomain example.com EOF
最后，为了防止NetworkManager等其他服务再次修改此文件，需要锁定它：
chattr +i /etc/resolv.conf
要解锁修改时，使用
chattr -i /etc/resolv.conf
。注意，在容器或云主机环境中，DHCP客户端也可能覆盖该文件，需一并检查。
高级技巧：DNS缓存、DNSSEC与DNS-over-TLS配置
systemd-resolved内置了DNS缓存，能加速重复查询。你可以用
resolvectl statistics
查看缓存命中率。它还支持DNSSEC（DNS安全扩展），通过在resolved.conf中设置“DNSSEC=yes”来强制验证，防止DNS欺骗。更前沿的功能是配置DNS-over-TLS (DoT) 来加密DNS流量，提升隐私性。在/etc/systemd/resolved.conf.d/目录下创建一个新配置文件，例如10-dot.conf：
[Resolve] DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google DNSOverTLS=opportunistic
这里“opportunistic”表示尝试使用TLS，但如果失败则回退到普通DNS。设置为“yes”则强制要求TLS。配置后同样需要重启服务。
诊断常见DNS问题：超时、慢、解析失败
当出现DNS问题时，按步骤排查。首先，检查当前有效的配置：
cat /etc/resolv.conf resolvectl status
其次，使用dig或nslookup测试解析，注意指定查询服务器以区分是本地存根解析器问题还是上游问题：
dig baidu.com # 使用系统默认（通常是127.0.0.53） dig baidu.com @8.8.8.8 # 直接向上游8.8.8.8查询
如果直接查询快而系统默认慢，问题很可能出在systemd-resolved或其配置的上游服务器。检查服务状态和日志：
systemctl status systemd-resolved journalctl -u systemd-resolved -f
常见错误包括：上游服务器不可达、网络防火墙阻断53端口、或systemd-resolved与容器（如Docker）的DNS配置冲突（Docker可能会修改/etc/resolv.conf）。
与网络管理服务（NetworkManager, systemd-networkd）的协同
systemd-resolved通常不是单独工作的。在桌面环境，NetworkManager是主角，它会从DHCP获取DNS设置并推送给systemd-resolved。你可以用
nmcli device show eth0
查看NetworkManager管理的DNS配置。在服务器环境，可能使用systemd-networkd。它的配置文件（如/etc/systemd/network/20-wired.network）中可以指定DNS：
[Network] DHCP=yes [DHCP] UseDNS=yes [Network] DNS=10.0.0.1 Domains=~lab.internal
关键在于理解优先级：网络管理服务（如NetworkManager）的接口级配置通常覆盖resolved.conf中的全局配置。统一管理入口能减少混乱。
最佳实践与总结建议
对于大多数现代Debian系统（尤其是桌面版或使用复杂网络的服务版），建议接受并熟练使用systemd-resolved。它的动态管理、缓存、DNSSEC和DoT支持能带来更好的体验和安全性。配置时，优先通过/etc/systemd/resolved.conf或对应网络管理工具进行。仅在极简环境或明确需求时，才考虑禁用并改用静态resolv.conf。记住，/etc/resolv.conf在现代系统中更多是一个“指向当前解析器”的指针，而非配置源。掌握resolvectl和systemd-resolve --status这两个诊断工具，是高效运维Debian DNS的关键。定期检查日志，确保你的DNS配置既符合网络策略，又能提供快速、可靠的解析服务。
