配置服务器的dns的文件是什么，服务器dns配置文件在哪？

配置服务器的dns的核心文件是/etc/resolv.conf，在绝大多数Linux发行版中，这个文本文件直接决定系统向哪个域名服务器发起解析请求。如果你改的是网卡配置或防火墙规则，唯独漏了它，DNS配置基本等于没改，这篇文章会把这个文件的底细、修改方法、以及改了之后不生效的坑全部讲透。

服务器dns配置文件在哪：先弄清路径再动手

业内有共识：Linux服务器上几乎所有与域名解析相关的本地设置，最终都会汇总到/etc/resolv.conf，这个文件不需要额外安装，任何一个主流发行版都会自带,你可以用下面这个命令直接查看当前服务器的DNS指向：

cat /etc/resolv.conf

一般长这样：

nameserver 223.5.5.5
nameserver 8.8.8.8
search example.com
options timeout:2

• nameserver：指定DNS服务器IP，最多可以写三行,系统按顺序尝试。
• search：补全主机名时自动追加的域名后缀,常用于内网环境。
• options：调整解析超时、旋转等行为,一般不需要动。

这个文件只负责“把域名交给谁去查”，不负责维护解析记录本身，搞清楚这一点，你就不会在修改文件后去怀疑防火墙有没有放行53端口那是另一码事。

配置linux服务器dns永久生效：别只改resolv.conf

很多人用echo "nameserver 114.114.114.114" > /etc/resolv.conf把文件覆盖掉，当时测试dig baidu.com没问题，结果重启机器或重启网络服务后，DNS又变回原来的值，原因很简单：你改的是“临时显示”的文件,而系统里还有其他服务在管理它。

谁在背后覆盖resolv.conf

目前最常见的覆盖者是systemd-resolved，如果你的服务器使用systemd（CentOS 7+、Ubuntu 16.04+基本都是），系统可能会把

/etc/resolv.conf软链接到/run/systemd/resolve/stub-resolv.conf，这时候你直接往/etc/resolv.conf，相当于改了一个指向内存的链接,系统一刷新就被还原。

先执行ls -l /etc/resolv.conf，看输出里有没有->箭头，如果有，说明文件被接管,你需要从源头改：

systemctl disable systemd-resolved
systemctl stop systemd-resolved

然后删掉软链接,重新创建普通文件再写入DNS。

不同发行版的持久化改动方式

行业里不存在一个“放之四海而皆准”的目录,因为每家发行版的网络管理工具不一样。

以Ubuntu 22.04为例,在Netplan文件里的DNS配置段长这样：

nameservers:
  addresses: [223.5.5.5, 119.29.29.29]

修改后执行sudo netplan apply，再重启一次网络服务，这一步做完，才算真正达到“linux服务器dns配置永久生效”的标准。

云服务器VPS的DNS配置差异

酷番云、简米云、AWS等云厂商的控制台里一般都有“DNS设置”选项，如果你在操作系统层面改了DNS，但控制台里还开着“DHCP自动分配”，重启后网络管理工具会拉取云平台下发的DNS配置，覆盖你本地写好的内容，多数情况下，云服务器建议保留平台默认的内网DNS，速度更快,还能自动解析内网主机名。

服务器dns配置验证：改完必须检查三个层面

配置写完不等于万事大吉，建议按顺序执行下面三步,确认内外网解析都正常。

查看当前生效的解析配置

cat /etc/resolv.conf是第一步，但只代表“文件内容”，系统实际使用的可能有缓存或叠加配置，用resolvectl status能看到systemd-resolved实时生效的DNS列表。

测试DNS服务器可达性

DNS走的是UDP 53端口,先确认你写的DNS服务器能通：

ping -c 3 223.5.5.5

IP能通，说明网络链路没问题，如果通但域名解析失败,大概率是53端口被防火墙挡了。

对比解析结果是否准确

nslookup example.com

输出里Server后面显示的地址，应该和你配置的nameserver一致，如果显示的是0.0.53这类本地回环地址，说明请求先经过本地缓存，再转发到上游DNS,这时候需要检查转发配置是否正确。

常见问题排查：改完dns配置文件不生效

“配置服务器的dns的文件是什么”这个问题背后，通常跟着一句话“我改了但没反应”,我把频率最高的三种情况列在下面。

文件权限导致写入失败

/etc/resolv.conf默认归属root，普通用户没有写权限，如果你用sudo写入后仍然提示Read-only file system,检查一下文件是否被chattr加锁：

lsattr /etc/resolv.conf

如果有i属性，执行chattr -i /etc/resolv.conf解锁后再改。

DHCP客户端覆写resolv.conf

如果你的网络接口使用DHCP获取IP，客户端的DHCP租约里可能携带DNS字段，并且每次续租都会重写resolv.conf，关闭DHCP对DNS的管理,需要修改DHCP客户端配置：

• dhclient：在/etc/dhclient.conf里添加supersede domain-name-servers 223.5.5.5;
• NetworkManager：编辑连接配置，将DNS从“自动”改为“手动”

容器场景下没有resolv.conf控制权

Docker容器默认继承宿主机的DNS配置，但容器内部看到的/etc/resolv.conf由Docker守护进程生成，想为单个容器指定DNS，启动时加--dns参数：

docker run --dns 223.5.5.5 nginx

docker compose则在service节点下声明dns字段。

docker compose场景补充

services:
  nginx:
    dns:
      - 223.5.5.5
      - 119.29.29.29

配置服务器的dns的文件是什么：Q&A

修改resolv.conf之前需要备份吗？

建议同步备份，虽然覆盖后可以重启网络服务临时重新生成，但某些定制化配置（比如search列表和options参数）可能丢失，执行cp /etc/resolv.conf /etc/resolv.conf.bak一条命令就能让后续调试有回退余地。

为什么推荐使用阿里DNS或腾讯DNS，而不是8.8.8.8？

8.8.8是谷歌提供的公共DNS，解析成功率高，但物理距离较远，国内服务器访问它需要跨境链路，延迟通常在50ms以上，部分运营商还会劫持53端口流量，阿里DNS（223.5.5.5）和腾讯DNS（119.29.29.29）在国内节点覆盖更密，解析CDN资源时能拿到就近地址，如果你的服务器在国内，优先选这两个；如果部署在海外，再用8.8.8和1.1.1组合。

配置了多个nameserver，为什么只看到第一个在工作？

glibc的解析器依顺序尝试nameserver，只有当第一个超时无响应时，才会转向第二个，所以检查配置时，把最快的DNS放在第一行，能显著降低域名解析的等待时间。