域名解析是网络请求的第一步，解析快慢看似只差几十毫秒，但在高并发场景下积少成多，影响不容小觑。不少人在云服务器上遇到过这样的怪事：明明改好了DNS配置，重启网络服务后配置却莫名其妙地变了回去，或者解析时快时慢。这类问题大多不是玄学，而是对系统的DNS管理机制理解不够到位。这篇文章从配置文件讲起，把云服务器上DNS的配置方法和优化思路完整梳理一遍。
一、理解Linux系统中的DNS配置文件
Linux系统里最核心的DNS配置文件是/etc/resolv.conf，它决定了系统向哪些DNS服务器发起解析请求。文件内容通常包含几个关键字段：nameserver指定DNS服务器地址，最多可以写三个；search定义域名搜索列表，访问短主机名时会自动拼接这些后缀；options可以设置超时时间、尝试次数等参数。
一个典型的配置如下：
# /etc/resolv.conf nameserver 223.5.5.5 nameserver 114.114.114.114 search mycompany.internal options timeout:2 attempts:3 rotate
这里有几个细节值得注意。rotate参数让系统在多个nameserver之间轮询，而不是每次都优先使用第一个，可以起到简单的负载均衡作用。timeout:2表示单个DNS服务器等待2秒无响应就切换到下一个，默认值是5秒，在网络环境较好的云服务器上适当调小能明显加快故障切换速度。
但直接编辑这个文件往往会遇到一个问题：重启之后修改的内容全部丢失。这是因为resolv.conf在很多发行版上只是一个由其他服务托管的文件，接下来就分析是谁在背后覆盖你的配置。
二、搞清楚谁在接管你的DNS配置
Ubuntu 18.04之后的版本默认启用了systemd-resolved服务，此时resolv.conf是一个软链接，指向/run/systemd/resolve/stub-resolv.conf。真正的上游DNS配置存放在/etc/systemd/resolved.conf中。如果只修改软链接指向的文件，一旦服务重启就会被打回原形。
正确的做法是编辑/etc/systemd/resolved.conf，设置DNS=和FallbackDNS=字段：
# /etc/systemd/resolved.conf [Resolve] DNS=223.5.5.5 119.29.29.29 FallbackDNS=8.8.8.8 # 重启服务生效 systemctl restart systemd-resolved # 验证当前实际生效的配置 resolvectl status
如果服务器上运行的是NetworkManager（常见于CentOS或桌面环境），则需要在网卡连接配置里设置DNS，或者直接用命令行工具修改：nmcli con mod eth0 ipv4.dns "223.5.5.5 119.29.29.29"，然后执行nmcli con up eth0重新激活连接。对于运行云厂商内部Agent的实例（比如某些镜像预装的网络管理工具），还要留意Agent是否会在开机时重写DNS，必要时可以在云控制台的私有网络设置中统一管理。
三、公共DNS怎么选，用数据说话
选择公共DNS不能只看名气，解析速度与服务器所在地域、运营商线路强相关。国内常用的选择包括阿里云的223.5.5.5、腾讯的119.29.29.29、114DNS的114.114.114.114，国际上有Google的8.8.8.8和Cloudflare的1.1.1.1。海外DNS在国内访问延迟普遍偏高，而且存在解析结果不够精准的问题，一般只作为备用。
衡量一个DNS快不快，最直接的办法是实测。dig命令是首选工具，它能给出完整的解析耗时：
# 测试解析耗时，关注 QUERY TIME 字段 dig @223.5.5.5 www.ippipp.com | grep "Query time" dig @119.29.29.29 www.ippipp.com | grep "Query time" dig @114.114.114.114 www.ippipp.com | grep "Query time" # 没有dig时可以用nslookup nslookup www.ippipp.com 223.5.5.5
建议在业务低峰和高峰各测一轮，每轮测试多个域名取平均值。除了速度，还要考虑防劫持能力和解析准确度。一些小众DNS存在广告注入或解析结果被污染的案例，选择大厂服务相对稳妥。另外，云服务器访问同厂商的内网DNS通常速度最快，因为解析请求不需要走出机房，比如阿里云ECS使用100.100.2.136，这类内网地址延迟往往只有个位数毫秒，值得优先使用。
四、进阶优化：缓存与TTL的合理运用
默认情况下，Linux系统每次解析域名都会向上游DNS发起请求，即使同一个域名在一秒内被请求了上百次。开启本地缓存可以把重复解析的开销降到接近零。除了前面提到的systemd-resolved自带缓存，也可以安装dnsmasq或unbound作为本地缓存服务器：
# 安装dnsmasq并配置缓存 yum install -y dnsmasq # CentOS apt install -y dnsmasq # Debian/Ubuntu # /etc/dnsmasq.conf 关键配置 no-resolv server=223.5.5.5 server=119.29.29.29 cache-size=10000 no-negcache systemctl enable --now dnsmasq # 把系统DNS指向本机 echo "nameserver 127.0.0.1" > /etc/resolv.conf
配置完成后，用dig www.ippipp.com @127.0.0.1连续查询两次，第二次的Query time应该接近0ms，说明缓存已经生效。对于运行大量外部请求的应用（比如爬虫、微服务间调用外部API），本地缓存带来的收益非常可观。
另一个容易被忽视的点是域名自身的TTL设置。如果域名是你自己管理的，迁移服务器或更换IP前，提前把TTL调低到60秒左右，可以加快切换生效速度；日常稳定运行时则可以适当调大，减轻DNS服务压力。同时注意排查应用层是否有不当的长连接DNS缓存行为，比如某些Java应用默认缓存DNS结果30秒以上，容器环境里也常见解析不更新的问题，需要结合具体运行时进行调整。
最后建议建立一个简单的监控机制，定期用脚本检测DNS解析是否正常，一旦发现解析超时率上升，及时切换备用DNS。域名解析虽小，却是整个服务链路的入口，把它配置稳妥了，后续的稳定性工作才有意义。