前几天工作中遇到一个问题：一个内部服务突然无法访问了。
刚开始以为是服务挂了，但检查后发现进程正常、端口也正常。继续排查后才发现，问题出在 DNS 解析上：域名没有正确解析到对应的服务器 IP，导致访问失败。修复 DNS 记录后，服务很快恢复正常。
这次问题也让我意识到，DNS 虽然平时不太被注意，但一旦出问题，就可能直接影响服务访问。所以今天就来简单聊聊 DNS 是什么，以及它是如何工作的。
不知道你有没有遇到过这种情况：在 Linux 服务器上 ping 一个域名，提示“未知的名称或服务”。
换个网络又能解析。
手动改了 /etc/resolv.conf，重启网络后配置又被打回原形。
域名明明已经改了解析记录，服务器却还在访问旧 IP。
DNS 天天用，但很多人对它的理解停留在一句话：把域名变成 IP。
这句话没错，但太粗了。
真正排障时，你需要知道的是：Linux 收到一个域名后，到底按什么顺序查？谁会缓存？哪个配置文件说了算？
这篇先把 Linux 本机解析链路讲透。下篇再讲工具、典型故障和加密 DNS。
一、DNS 不只是“域名转 IP”
DNS 的全称是 Domain Name System，中文一般叫域名系统。
它不是一台服务器，也不是一个简单的转换器，而是一套分布式、分层的查询体系。
从根域名服务器，到顶级域服务器，再到权威 DNS 服务器，最终回答某个域名对应什么记录。
但今天我们不展开全球 DNS 体系。
我们只聚焦一个更贴近运维的问题：
在 Linux 上，一个程序要解析域名时，本机到底怎么决定去哪里查？
比如你执行：
curl https://www.example.com
系统不是一上来就直接问 /etc/resolv.conf 里的 DNS 服务器。
中间至少会涉及：
- nscd、systemd-resolved、dnsmasq 等缓存或转发服务
所以很多 DNS 问题看起来像“DNS 服务器坏了”，其实根源在本机解析链路上。
二、第一道关：nsswitch.conf 决定先查谁很多人只知道 /etc/resolv.conf，却忽略了 /etc/nsswitch.conf。
它才是 Linux “名字服务”的调度表。
看这一行：
grep '^hosts:' /etc/nsswitch.conf
常见输出类似：
hosts: files dns
这里的意思是：
files：先查本地文件，主要是 /etc/hosts
所以当 /etc/hosts 里已经写了某个域名时，很多程序会优先拿 hosts 的结果，而不是继续查 DNS。
例如：
127.0.0.1 www.example.com
这时你再怎么改 DNS 服务器，系统解析 www.example.com 时仍然可能先拿到 127.0.0.1。
这就是为什么排查域名异常时，我通常第一眼先看：
grep 'example.com' /etc/hosts
注意，不同发行版的 hosts: 行不一定只有 files dns。
你可能看到：
hosts: files mdns4_minimal [NOTFOUND=return] dns
也可能看到：
hosts: files resolve [!UNAVAIL=return] dns
这里的 resolve 通常表示通过 systemd-resolved 的 NSS 模块查询；mdns4_minimal 常用于局域网 .local 名称解析。
别死记“永远 files dns”。
你要记住的是：Linux 系统解析主机名时，先看 nsswitch.conf 的 hosts 行。
三、第二道关：/etc/hosts 是最容易被忽略的“本地答案”
/etc/hosts 很简单，但杀伤力很大。
它像一本本地通讯录。
只要里面写了：
10.0.0.5 api.example.com
系统就可能直接把 api.example.com 解析到 10.0.0.5。
这在测试环境很常见。
临时切后端、灰度验证、绕过 DNS，都可能手动加 hosts。
但问题是：人会忘。
半年后域名已经迁移，DNS 记录也改了，服务器还访问旧 IP。最后查半天发现，是 /etc/hosts 里藏了一行旧配置。
所以记住一个排障习惯：
getent hosts api.example.comgrep 'api.example.com' /etc/hosts
前者看系统实际解析结果，后者看是不是 hosts 写死。
这比一上来就改 DNS 服务器靠谱得多。
四、第三道关：本机到底有没有 DNS 缓存？
很多文章会说：“Linux 会先查本地 DNS 缓存。”
这句话不够严谨。
传统 glibc resolver 本身通常不提供一个统一的系统级 DNS 缓存。Linux 是否有本地缓存，取决于你有没有启用相关服务。
常见情况有几类。
1. nscd：老牌名字服务缓存
nscd 是 Name Service Cache Daemon。
它可以缓存 NSS 查询结果，包括 hosts、passwd、group 等。
如果系统启用了 nscd，清 hosts 缓存可以用：
sudo nscd -i hosts
或者重启服务：
sudo systemctl restart nscd
但现在不少发行版并不默认启用 nscd。
所以不要一遇到 DNS 问题就默认“肯定有 nscd 缓存”。
先查：
systemctl status nscd
2. systemd-resolved：常见于 Ubuntu 等系统
很多新系统使用 systemd-resolved 负责本地解析、缓存、DNSSEC、DoT 等能力。
Ubuntu 18.04+ 常见这种模式。
但要注意：CentOS/RHEL 7/8 默认并不等于一定启用了 systemd-resolved。它们更常见的是 NetworkManager 管理网络配置，是否使用 resolved 要看实际系统。
判断方法：
systemctl status systemd-resolvedls -l /etc/resolv.conf
如果 /etc/resolv.conf 指向类似路径：
/run/systemd/resolve/stub-resolv.conf
并且里面是：
nameserver 127.0.0.53
说明本机程序通常会把 DNS 请求发给本地 stub，再由 systemd-resolved 转发到真正的上游 DNS。
查看统计信息：
resolvectl statistics
清缓存：
sudo resolvectl flush-caches
老系统上你也可能看到：
systemd-resolve --statisticssystemd-resolve --flush-caches
新系统更推荐用 resolvectl。
3. dnsmasq、unbound、named：本地递归或转发器
有些服务器会跑本地 DNS 转发器，例如：
这种情况下，/etc/resolv.conf 里可能写的是：
nameserver 127.0.0.1
这并不是“DNS 配错了”，而是让本机先问本地 DNS 服务。
排查时要继续看本地服务的配置和缓存，而不是只盯着 /etc/resolv.conf。
五、/etc/resolv.conf 到底管什么？
当解析流程需要走 DNS 时，传统 resolver 会参考 /etc/resolv.conf。
一个典型配置可能是：
nameserver 114.114.114.114nameserver 8.8.8.8search example.com local.domainoptions timeout:2 attempts:3 rotate ndots:1
逐行看。
1. nameserver：上游 DNS 服务器
nameserver 后面写的是 DNS 服务器地址。
传统 glibc resolver 对 nameserver 数量有上限，常见上限是 3 个。也就是说，你写一长串并不一定都会被使用。
多个 nameserver 默认不是同时问。
通常是按顺序使用：先问第一个，超时或不可用时再尝试后面的。
如果配置了：
options rotate
glibc resolver 会在多个 nameserver 之间轮转起始选择，用来分散请求压力。
这里也要严谨一点：rotate 不是“随机选一个”，而是轮转。
2. search：自动补全域名后缀
search 是搜索域后缀。
例如：
search example.com
你执行：
ping git
系统可能会尝试解析：
git.example.com
这在企业内网很方便。
但如果 search 后缀太多，或者应用频繁访问短域名，就会增加额外 DNS 查询，导致延迟变高。
所以 search 不是越多越好。
3. timeout 和 attempts：超时与重试
options timeout:2 attempts:3
timeout 控制每次查询等待响应的时间，单位是秒。
attempts 控制重试轮数。
这两个值设得过大，DNS 故障时应用会卡很久。
设得过小，又可能在网络抖动时误判失败。
生产环境里要结合网络质量和业务容忍度设置，不建议盲目照抄。
4. ndots：Kubernetes 里最容易踩坑的参数
ndots 决定一个名字在什么情况下先按“绝对域名”尝试。
例如：
options ndots:1
如果域名里的点数量大于等于 1，比如 www.example.com，resolver 通常会先尝试原始名字。
如果是 git 这种没有点的短名字，就会先尝试拼接 search 后缀。
Kubernetes 里经常看到：
options ndots:5
这会导致很多外部域名，比如 api.example.com，因为点数少于 5，先被拿去拼接一堆集群内 search 后缀，最后才查原始域名。
结果就是：能解析，但慢。
DNS 排障里，“慢”有时候比“不通”更隐蔽。
六、为什么手动改 resolv.conf，重启后又变回去？
这是新手最常见的问题之一。
原因很简单：很多现代 Linux 系统里，/etc/resolv.conf 不是最终配置源，而是由网络管理服务生成的结果文件。
可能管理它的有：
所以你手动改它，服务一重启，DHCP 一续租，文件就被重新生成了。
正确做法是改“配置源”。
使用 NetworkManager
查看连接名：
nmcli connection show
修改 DNS：
sudo nmcli connection modify "连接名" ipv4.dns "114.114.114.114 8.8.8.8"sudo nmcli connection modify "连接名" ipv4.ignore-auto-dns yessudo nmcli connection up "连接名"
如果你希望继续使用 DHCP 但忽略 DHCP 下发的 DNS，就需要 ipv4.ignore-auto-dns yes。
使用 systemd-resolved
可以改 /etc/systemd/resolved.conf：
[Resolve]DNS=114.114.114.114 8.8.8.8FallbackDNS=1.1.1.1
然后：
sudo systemctl restart systemd-resolvedresolvectl status
使用 netplan
Ubuntu 服务器常见 netplan。
示例：
network:version:2ethernets:eth0:dhcp4:noaddresses:-192.168.1.10/24routes:-to:defaultvia:192.168.1.1nameservers:addresses:-114.114.114.114-8.8.8.8
应用配置：
sudo netplan apply
不推荐把 chattr +i 当常规方案
网上经常有人建议：
sudo chattr +i /etc/resolv.conf
这确实能防止文件被改。
但它是“锁文件”，不是“正确配置网络”。
生产环境里它可能影响 DHCP、NetworkManager、云主机初始化、容器网络等正常行为。
只有在临时救急、你明确知道后果时，才考虑这么做。
日常运维更推荐从 NetworkManager、systemd-resolved、netplan 等配置源头解决。
七、上篇小结
Linux DNS 排障不要一上来就改 /etc/resolv.conf。
先把解析链路看清楚：
nsswitch.conf 决定先查 hosts 还是 DNS。- Linux 不一定有系统级 DNS 缓存，要看 nscd、systemd-resolved、dnsmasq 等服务是否启用。
/etc/resolv.conf 只是 DNS 查询配置的一部分，而且经常是生成文件。search、ndots、timeout、attempts 会显著影响解析行为和延迟。
下篇我们继续讲：ping、dig、nslookup、getent 到底有什么区别，以及几个最常见的 DNS 故障该怎么一步步定位。
10个月宝宝每天需要喝多少奶粉？
