这个场景解决什么
域名解析出问题比连通性问题更容易误判，因为「解析」这条链路上有三段：本机的名字服务开关与 hosts 文件、本机配置的 DNS 服务器、以及再往上的权威服务器。排查方法是分段验证：先用 getent 看系统真实解析结果，再用 dig 逐级直问，最后对比缓存与权威的答案。这样才能区分是本地配置问题、上游缓存问题，还是权威记录本身有问题。
基本信息
| 适用场景 | 解析失败、解析结果不对、只有个别机器解析异常 |
|---|---|
| 核心工具 | getent 验证系统实际结果，dig 逐级查询，resolvectl 查看本地解析服务状态 |
| 关键文件 | /etc/nsswitch.conf 决定查询顺序，/etc/hosts 通常优先于 DNS |
| 判断原则 | 先分清「解析问题」与「连通问题」，两者报错表现完全不同 |
典型使用场景
- 应用报未知主机：应用连不上某个域名，先确认是解析不到还是连不上
- 改了 DNS 记录不生效：区分是本地缓存、上游缓存还是 TTL 未到期
- 只有一台机器异常：优先怀疑该机的 hosts 文件与 nsswitch 配置
- 内网域名分裂解析：内外网同名域名指向不同地址，验证是否命中了预期的解析路径
- 切换 DNS 服务后验证：确认新配置真的生效，而不是被本地缓存掩盖
第 1 步：系统实际解析路径
第 1 步：系统实际解析路径
getent hosts app.example.com # 走 nsswitch 的真实结果，含 /etc/hosts
grep -v '^#' /etc/hosts | grep -i app # 本地是否有手工记录
grep ^hosts /etc/nsswitch.conf # 确认 files 与 dns 的先后顺序
getent ahostsv4 app.example.com | head # 只看 IPv4 结果第 2 步：逐级对照查询
第 2 步：逐级对照查询
dig +short app.example.com # 用本机配置的 DNS
dig +short @1.1.1.1 app.example.com # 换公共 DNS 对照
dig +short @10.0.0.53 app.example.com # 直问内网 DNS
dig +short @ns1.example.com app.example.com # 直问权威服务器
dig +noall +answer app.example.com # 看 TTL，判断缓存还有多久过期第 3 步：缓存与服务
第 3 步：缓存与服务
resolvectl status # systemd-resolved 的分流与上游配置
resolvectl query app.example.com # 用 resolved 自己的解析结果
resolvectl flush-caches # 清本地缓存后重查
curl -sS --resolve app.example.com:443:10.0.0.9 https://app.example.com/ -I # 绕过 DNS 直测目标 IP三段解析路径对照
| 环节 | 查什么 | 异常表现 |
|---|---|---|
| /etc/hosts 与 nsswitch | 本地是否有记录、查询顺序如何 | 只有个别机器结果不同，其它机器正常 |
| 本机配置的 DNS | dig 不带 @ 的结果与上游是否一致 | 整批机器都解析失败或拿到旧地址 |
| 缓存与 TTL | 答案里的 TTL 是否在递减 | 改了记录但一段时间内仍是旧值 |
| 权威服务器 | 直问权威是否返回预期记录 | 全网都拿不到正确结果，属于记录本身的问题 |
「只有某台机器解析不对」几乎总能在 /etc/hosts 或 nsswitch 里找到答案；「整批机器都不对」则要往上游缓存与权威记录方向查，别在单机上耗时间。
dig 默认不读 /etc/hosts，也不走本机的名字服务开关，所以它给出的结果可能与应用的实测行为不同。要模拟应用行为，用 getent 验证才准。