在Linux系统中，DNS解析的核心配置位于/etc/resolv.conf文件，而systemd-resolved是现代发行版中管理解析的主要服务，两者常常协同工作但也容易引发冲突。
Linux DNS解析的两种主流模式
传统/etc/resolv.conf配置
多年来,Linux的DNS配置一直依赖/etc/resolv.conf文件，这个文件包含nameserver、search和domain等指令，系统解析时，会按顺序尝试文件中列出的nameserver，直到获得响应，传统模式简单直接，但也有明显缺点：任何进程都可以修改这个文件，导致配置被意外覆盖，尤其在NetworkManager、dhclient等网络管理工具介入时。
systemd-resolved与resolvectl
随着systemd成为主流初始化系统,systemd-resolved成为处理DNS解析的新方案，它默认监听127.0.0.53，并将/etc/resolv.conf软链接到/run/systemd/resolve/stub-resolv.conf。resolvectl是管理systemd-resolved的命令行工具，可以查看当前DNS服务器、缓存状态和链路配置，相比传统模式，systemd-resolved支持缓存、DNSSEC验证和多链路合并，但需要额外学习成本。
| 特性 | 传统resolv.conf | systemd-resolved |
|---|---|---|
| 配置文件 | /etc/resolv.conf | 通过resolvectl设置 |
| 缓存 | 无 | 内置缓存，可加速解析 |
| 管理工具 | 手动编辑 | resolvectl命令 |
| 多链路支持 | 需手动配置 | 自动按链路合并 |
| 兼容性 | 所有应用直接读取 | 应用默认通过127.0.0.53查询 |
linux resolve.conf配置常见错误与解决
如何检查当前DNS配置
使用cat /etc/resolv.conf查看传统文件内容，如果看到nameserver 127.0.0.53，说明系统正在使用systemd-resolved，此时运行resolvectl status可以查看所有网络接口的DNS服务器、DNS域和缓存统计，如果
resolvectl不可用，可以检查systemd-resolved服务是否启动：systemctl status systemd-resolved。
配置被覆盖怎么办
很多用户遇到的问题是,手动编辑/etc/resolv.conf后，重启网络或重启系统后配置被重置，这是因为NetworkManager或dhclient默认会覆盖这个文件，解决方法：
- 如果使用NetworkManager,可以在连接配置中设置DNS，或关闭NetworkManager的DNS管理功能：在
/etc/NetworkManager/NetworkManager.conf中设置dns=none。 - 如果使用systemd-networkd，可以通过
resolvectl设置链路DNS：resolvectl dns eth0 8.8.8.8。 - 最简单的做法是将/etc/resolv.conf设置为不可变：
chattr +i /etc/resolv.conf，但这样会阻止任何动态更新，适合稳定环境。
使用resolvectl命令配置永久生效
对于使用systemd-resolved的系统，推荐使用resolvectl进行配置，为接口eth0设置永久DNS（重启后依然有效）：resolvectl dns eth0 8.8.8.8 1.1.1.1resolvectl domain eth0 example.com
这些设置会被保存在/etc/systemd/resolved.conf和对应的网络配置文件中，如果希望整个系统使用特定DNS服务器，可以编辑/etc/systemd/resolved.conf，设置DNS=和Domains=。
linux dns解析慢如何排查
使用dig和nslookup测试
当感觉域名解析变慢时,首先用dig检查解析耗时。dig www.baidu.com会显示查询时间（Query time），如果时间较长，可以分别测试不同DNS服务器，对比延迟。nslookup也可以快速查看解析结果，注意，如果使用systemd-resolved，dig默认会查询127.0.0.53，这代表本地缓存，如果缓存未命中，实际查询时间取决于上游DNS服务器。
调整缓存策略
systemd-resolved默认开启缓存，缓存大小可以通过/etc/systemd/resolved.conf中的Cache=
参数调整，通常设置为Cache=yes足够，如果缓存命中率低，可以考虑增加缓存大小或使用本地DNS代理如dnsmasq，对于传统模式，没有缓存，解析慢时直接检查上游DNS服务器响应速度，可以使用ping测试DNS服务器IP的延迟，或者使用traceroute查看路由路径。
常见原因与对策
- 上游DNS服务器响应慢：更换为公共DNS，如114.114.114、8.8.8或1.1.1。
- DNS查询超时：检查防火墙是否拦截UDP 53端口，或者尝试使用TCP 53。
- 系统负载过高导致解析进程阻塞：使用
top或htop查看CPU和内存使用，排查是否存在资源瓶颈。 - 配置了过多的DNS服务器：nameserver列表不宜超过3个，否则轮询会浪费等待时间。
生产环境DNS配置最佳实践
多网卡场景下的解析顺序
生产服务器通常有多个网络接口,如业务网卡和管理网卡，如果两者都配置了DNS，解析顺序可能混乱，在systemd-resolved中，可以通过resolvectl设置每个链路的DNS域，实现域名分流，内网域名查询走内网DNS，外网域名走公共DNS。resolvectl domain eth0 ~.表示eth0负责所有域名，或者指定特定域如resolvectl domain eth1 internal.example.com，在传统resolv.conf中，可以通过sortlist和options rotate控制顺序，但灵活性有限。
容器环境下的DNS配置
Docker容器默认使用宿主机的DNS设置,但有时需要独立配置，在docker-compose中，可以指定dns字段，或在/etc/docker/daemon.json中设置全局DNS，对于Kubernetes环境，CoreDNS负责集群内部域名解析，通常需要与宿主机DNS协同工作，行业共识认为，容器环境下应避免直接修改/etc/resolv.conf，而是通过容器编排工具定义DNS策略，确保配置可移植且不冲突。
配置变更后的验证
每次修改DNS配置后,务必从不同角度验证解析是否正常，推荐使用
dig +trace查看完整解析路径，确保没有错误，同时用ping测试外网域名的可达性，对于生产环境，建议先在一台测试机器上验证配置，再批量应用，如果发现解析失败，立刻使用resolvectl flush-caches（systemd-resolved）或重启网络服务。
linux resolve常见问题解答
什么是resolve.conf文件？它和systemd-resolved有什么关系？
/etc/resolv.conf是Linux系统传统的DNS解析器配置文件，它指定了域名服务器地址和搜索域，在现代systemd发行版中，这个文件通常被软链接到systemd-resolved的stub文件，实际解析由systemd-resolved通过127.0.0.53处理。resolve.conf文件是解析的入口，但实际工作由后端的systemd-resolved或传统glibc解析器完成。
systemd-resolved和传统resolv.conf冲突怎么办？
如果两者配置不一致,可能导致解析混乱，手动编辑/etc/resolv.conf后，systemd-resolved可能不会生效，或者反过来，解决方法：要么完全禁用systemd-resolved（使用传统模式），要么完全依赖systemd-resolved并通过resolvectl配置，推荐做法是保留systemd-resolved，并将/etc/resolv.conf保持为软链接，所有配置通过resolvectl进行，这样能避免冲突，并利用缓存和DNSSEC特性。
如何永久修改Linux系统的DNS服务器，重启后不丢失？
永久修改DNS的方法取决于使用的网络管理工具,对于NetworkManager，在连接配置中设置DNS（如nmtui或nmcli），对于systemd-networkd，在网络配置文件中添加DNS=，对于systemd-resolved，编辑/etc/systemd/resolved.conf并设置DNS=，无论哪种方式，最终都要确保/etc/resolv.conf指向正确的配置源。推荐使用resolvectl命令设置，它会将配置持久化到系统文件，重启后依然有效。
Linux下DNS解析的稳定性和性能，取决于对resolve.conf和resolvectl的正确理解与配置，掌握这两套工具，就能应对绝大多数解析场景，从开发机到生产环境都能游刃有余。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/511397.html
