DNS 解析与排查：从 resolv.conf 到 systemd-resolved 的实战排障指南

概述

凌晨两点，告警炸了。服务连不上数据库，curl 超时，但 ping IP 通。你说这到底是网络问题还是应用问题？十有八九是 DNS 解析出了岔子。

DNS 解析是 Linux 系统最基础也是最容易被忽视的基础设施。平时没人关注它，一旦出问题，整个系统像突然失忆了一样——所有域名都认不出来。更恶心的是，DNS 问题表现千奇百怪：有的直接报 Temporary failure in name resolution，有的莫名其妙卡 5 秒，有的间歇性失败。如果不清楚解析链路，排查起来就是一通乱试。

这篇文章把 Linux DNS 解析的完整链路拆开讲：从 /etc/hosts 到 nsswitch，从 resolv.conf 到 systemd-resolved，从 dig 到 tcpdump。每个环节配实战案例，看完能在生产环境独立排查 DNS 问题。

Linux DNS 解析的完整链路

先搞清楚一个问题：当你在终端敲下 curl http://example.com 的时候，系统到底干了什么？

DNS 解析不是一步完成的，它经过多个层级。理解这条链路是排查问题的前提。打个比方：DNS 解析就像寄快递。你写的收件地址是"北京市朝阳区"，快递员不会直接知道具体在哪——先查邮编分区，再查街道，最后查门牌号。DNS 也一样，一层一层往下找。

解析优先级

Linux 系统解析一个域名时，默认按以下顺序查找：

本地 hosts 文件（/etc/hosts）——优先级最高，匹配到就直接返回
DNS 缓存——如果系统装了 nscd 或 systemd-resolved，会先查缓存
配置的 DNS 服务器（/etc/resolv.conf 中的 nameserver）——最后才走网络查询

但这个顺序不是写死的。真正控制解析顺序的是 /etc/nsswitch.conf 文件中的 hosts 行：

# 查看 nsswitch 配置
cat /etc/nsswitch.conf | grep hosts

# 典型输出
hosts:      files dns myhostname

这行配置的意思是：先查 files（/etc/hosts），再查 dns（DNS 服务器），最后用 myhostname 机制。如果顺序变成 dns files，系统会先走 DNS 查询，性能完全不同。

坑点：有些系统的 nsswitch.conf 里 hosts 行缺少 dns 关键字，结果系统永远不会走 DNS 查询，只认 hosts 文件里的记录。症状是 dig 正常但 curl 失败。

一次完整的 DNS 查询流程

以 curl http://example.com 为例，完整流程如下：

应用程序 (curl)
    │
    ▼
glibc getaddrinfo()        ← C 标准库的解析入口
    │
    ├─→ /etc/nsswitch.conf  ← 决定查询顺序
    │
    ├─→ /etc/hosts          ← 第一步：查本地 hosts 文件
    │   (匹配则直接返回)
    │
    ├─→ nscd / systemd-resolved  ← 第二步：查本地缓存
    │   (命中缓存则直接返回)
    │
    └─→ /etc/resolv.conf    ← 第三步：走 DNS 查询
        │
        ▼
    nameserver 指定的 DNS 服务器
        │
        ▼
    递归查询：根域 → TLD → 权威服务器
        │
        ▼
    返回 IP 地址

关键点：dig 和 nslookup 这两个工具不走 glibc，它们直接构造 DNS 协议包发往指定的 DNS 服务器。这就是为什么有时候 dig 正常但 curl 失败——两者走的路径不同。

resolv.conf 的行为细节

/etc/resolv.conf 是 DNS 查询的核心配置文件。看起来简单，但里面的门道不少：

# 典型的 resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com internal.example.com
options timeout:2 attempts:3

参数	说明	默认值	生产建议
`nameserver`	DNS 服务器地址	无	至少配 2 个
`search`	短域名补全后缀	无	按实际域名配
`domain`	本地域名	无	与 search 互斥
`options timeout`	单次查询超时（秒）	5	建议设 2
`options attempts`	重试次数	2	建议设 3
`options rotate`	轮询使用多个 nameserver	关闭	高可用场景开启

最坑的行为：nameserver 支持最多 3 个 IPv4 地址（内核限制），第 4 个起被静默丢弃。而且它不是负载均衡——只有第一个超时后才会 fallback 到第二个。如果第一个 nameserver 配了内网 DNS 但网络不通，每次查询都要等 5 秒超时才会切到第二个。

踩坑实录：有次生产环境所有请求都卡 5 秒，排查发现 resolv.conf 第一个 nameserver 指向了一台已下线的 DNS 服务器。改为先配可用的，问题秒解。

systemd-resolved：朋友还是麻烦

现代 Linux 发行版（Ubuntu 18.04+、RHEL 8+、Fedora 33+）默认启用 systemd-resolved，它接管了 DNS 解析。好处是支持 DNS 缓存、DNS-over-TLS、每接口独立 DNS 配置。坏处是排查问题时多了一层中间人。

先确认系统是否在用 systemd-resolved：

# 方法1：看 resolv.conf 是不是符号链接
ls -l /etc/resolv.conf

# 如果输出类似下面，说明被 systemd-resolved 接管了
# lrwxrwxrwx 1 root root 39 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

# 方法2：看服务状态
systemctl is-active systemd-resolved

# 方法3：看实际 DNS 配置（这才是真实的）
resolvectl status

resolvectl status 的输出信息量很大：

Global
       Protocols: LLMNR=resolve -fL  MDNS=resolve -fL  DNSOverTLS=no
resolv.conf mode: stub
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 8.8.4.4
        DNS Domain: example.com

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: LLMNR=resolve MDNS=resolve DNSOverTLS=no
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
        DNS Domain: internal.example.com

经典坑：systemd-resolved 进程在运行、占着 127.0.0.53:53，但实际没配置上游 DNS 或处于 failed 状态。resolv.conf 指向它，所有请求卡在 connect timeout（默认 5 秒）。你手动改 resolv.conf 写 nameserver 8.8.8.8，但它会悄悄覆盖你的修改。

解决方法：

# 查看真实配置，如果显示 "No current DNS server" 就是它的问题
resolvectl status

# 临时绕过：改用 stub 模式
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# 或者直接停用 systemd-resolved（传统模式）
sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

排查工具链

DNS 排查有一套成熟的工具链。不是每个工具都每次用，但你需要知道什么场景用什么工具。

dig：DNS 排查的主力武器

dig（Domain Information Groper）是 DNS 排查最强大的工具。它直接构造 DNS 协议包发往指定服务器，绕过系统解析器。

基本查询：

# 基本查询，显示完整解析过程
dig example.com

# 关键输出字段：
# ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
# ;; QUESTION SECTION:    ← 你查了什么
# ;; ANSWER SECTION:      ← 返回了什么
# ;; SERVER: 8.8.8.8#53   ← 实际响应的 DNS 服务器
# ;; Query time: 23 msec  ← 响应时间

指定 DNS 服务器查询，排除本地配置干扰：

# 用 8.8.8.8 查询，绕过本地 DNS 配置
dig @8.8.8.8 example.com

# 用 1.1.1.1 查询对比结果
dig @1.1.1.1 example.com

# 如果两个公共 DNS 返回不同结果，可能是本地 DNS 被劫持

查询特定记录类型：

# A 记录（IPv4 地址）
dig example.com A

# AAAA 记录（IPv6 地址）
dig example.com AAAA

# MX 记录（邮件服务器）
dig example.com MX

# TXT 记录（文本记录，常用于验证）
dig example.com TXT

# NS 记录（域名服务器）
dig example.com NS

# SOA 记录（区域授权起始）
dig example.com SOA

跟踪完整解析路径，看从根域到最终结果的每一跳：

dig +trace example.com

# 输出示例（简化）：
# ;; QUERY: 1, ANSWER: 13
# .           518400  IN  NS  a.root-servers.net.     ← 根域服务器
# com.        172800  IN  NS  a.gtld-servers.net.     ← .com 顶级域
# example.com. 172800 IN  NS  a.iana-servers.net.      ← 权威服务器
# example.com. 300    IN  A   93.184.216.34            ← 最终结果

+trace 是排查 DNS 链路问题的利器。如果某一跳超时，你能精确定位是哪一层出了问题。

反向查询（IP 反查域名）：

# 反向 DNS 查询
dig -x 8.8.8.8

# 输出：
# ;; ANSWER SECTION:
# 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google.

DNSSEC 查询，验证域名是否启用了 DNS 签名：

dig +dnssec example.com

# 如果返回中含 ad flag（Authenticated Data），说明启用了 DNSSEC

精简输出，只看 IP 地址：

dig +short example.com
# 93.184.216.34

nslookup：快速验证的轻量工具

nslookup 功能比 dig 简单，但交互模式在批量查询时很方便：

# 基本查询
nslookup example.com

# 指定 DNS 服务器
nslookup example.com 8.8.8.8

# 查询特定记录类型
nslookup -type=MX example.com

# 交互模式（可连续查询）
nslookup
> server 8.8.8.8
> example.com
> example.com MX
> exit

dig vs nslookup 的关键区别：nslookup 默认走系统解析器（受 nsswitch.conf 和 systemd-resolved 影响），dig 默认直连 DNS 服务器。排查时两者对比能发现很多隐藏问题。如果 nslookup 慢但 dig 快，说明本地解析链路有问题。

host：最简洁的查询工具

# 基本查询，输出最简洁
host example.com

# 查询特定记录
host -t MX example.com
host -t NS example.com

# 详细输出
host -v example.com

# 反向查询
host 8.8.8.8

resolvectl：systemd-resolved 专用工具

如果系统用了 systemd-resolved，resolvectl 是必会的工具：

# 查看 DNS 配置状态
resolvectl status

# 查询指定域名
resolvectl query example.com

# 查看缓存统计
resolvectl statistics

# 清除 DNS 缓存
resolvectl flush-caches

# 重置链路配置
resolvectl revert eth0

tcpdump：终极抓包手段

当工具都查不出问题时，直接抓包看实际 DNS 流量：

# 抓取 DNS 流量（UDP 53 端口）
sudo tcpdump -i any -n port 53 -vv

# 抓取特定域名的 DNS 查询
sudo tcpdump -i any -n port 53 -vv | grep "example.com"

# 抓取 DNS 响应，看返回的 IP
sudo tcpdump -i any -n port 53 -vv -X

# 保存到文件用 Wireshark 分析
sudo tcpdump -i any -n port 53 -w dns.pcap

实战技巧：用 tcpdump 可以确认 DNS 查询包到底发出去了没有、发给了谁、有没有收到响应。如果连查询包都没发出去，说明应用层或 glibc 有问题；如果发出去了但没响应，说明网络或 DNS 服务器有问题。

常见故障场景与排查流程

场景一：域名完全解析不了

症状：curl 报 Temporary failure in name resolution 或 Could not resolve host。

排查流程：

# 第1步：确认是不是 DNS 问题（IP 能通但域名不通）
ping -c 2 8.8.8.8        # IP 通
ping -c 2 google.com     # 域名不通 → DNS 问题

# 第2步：检查 resolv.conf
cat /etc/resolv.conf
# 确认有有效的 nameserver

# 第3步：直连 DNS 服务器测试
dig @8.8.8.8 google.com
# 如果直连成功但系统解析失败 → 本地配置问题
# 如果直连也失败 → 网络问题或 DNS 服务器不可达

# 第4步：检查网络连通性
ping -c 2 $(awk '/^nameserver/{print $2; exit}' /etc/resolv.conf)
# 如果 DNS 服务器 ping 不通 → 网络路由问题

# 第5步：检查防火墙是否封锁 UDP 53 端口
sudo iptables -L -n | grep 53
# 或
sudo ufw status

场景二：DNS 解析特别慢

症状：所有请求莫名卡顿，偶尔超时。SSH 登录也慢。

这是最常见的隐藏 DNS 问题。原因通常有以下几种：

原因1：resolv.conf 第一个 nameserver 不可达

# 测试每个 nameserver 的响应时间
for ns in $(awk '/^nameserver/{print $2}' /etc/resolv.conf); do
    echo -n "$ns: "
    dig @$ns example.com +stats 2>/dev/null | grep "Query time" || echo "timeout"
done

# 如果第一个超时，修改 resolv.conf 调整顺序
# 或加 options timeout:1 减少超时等待

原因2：IPv6 解析问题

很多应用默认会先尝试 IPv6（AAAA 记录）解析，如果系统不支持 IPv6 或 IPv6 DNS 不可达，会先等 AAAA 查询超时再退回 A 记录查询。

# 检查是否启用了 IPv6
ip -6 addr show

# 如果不需要 IPv6，禁用它避免 AAAA 查询超时
# 方法1：在 resolv.conf 中加 options（不推荐，可能被覆盖）
# 方法2：在应用层禁用 IPv6
# curl 禁用 IPv6
curl -4 http://example.com
# wget 禁用 IPv6
wget -4 http://example.com

原因3：ndots 配置导致的额外查询

resolv.conf 中的 options ndots:N 参数控制何时进行完全限定域名查询。默认值是 1（旧系统）或 5（systemd-resolved 系统）。

# 查看 ndots 配置
cat /etc/resolv.conf | grep options

# 如果 ndots:5，意味着：
# 查询 "db" 这种短名时，会先尝试：
#   db.search-domain1.com  ← 先用 search 补全
#   db.search-domain2.com
#   ...
#   db                     ← 最后才查裸域名
# 每次补全失败都会产生一次 DNS 查询，总共 6 次查询

Kubernetes 环境下这个问题尤其严重。Pod 的默认 resolv.conf 是这样的：

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

这意味着查询 example.com（只有 1 个点，小于 5），系统会先尝试：

# 实际会触发 4 次无意义的 DNS 查询
example.com.default.svc.cluster.local     → NXDOMAIN
example.com.svc.cluster.local             → NXDOMAIN
example.com.cluster.local                 → NXDOMAIN
example.com                               ← 最后才查真正的域名

生产教训：K8s 集群里一个应用对外请求慢，最后查出来是每次都要多 3 次 DNS 查询。解决方案：要么在 Pod 级别修改 dnsPolicy 和 dnsConfig，要么对外部域名使用全限定域名（加 . 后缀，如 example.com.）。

场景三：间歇性解析失败

症状：时好时坏，没有规律。这种最难排查。

# 持续监控 DNS 解析，记录失败时间
while true; do
    timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    result=$(dig +short +time=2 +tries=1 example.com 2>&1)
    if [ -z "$result" ] || echo "$result" | grep -q "timed out"; then
        echo "[$timestamp] FAILED: $result"
    else
        echo "[$timestamp] OK: $result"
    fi
    sleep 5
done

间歇性失败的常见原因：

DNS 服务器负载高：多台机器同时查询一个 DNS 服务器，高峰期响应不过来
UDP 包丢失：DNS 默认用 UDP，丢包率高时会出现间歇性失败
连接跟踪表满：nf_conntrack 表满了会导致 UDP 包被丢弃
DNS 服务器超载：单台 DNS 服务器 QPS 超限

# 检查连接跟踪表
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# 如果 count 接近 max，增大限制
echo 262144 | sudo tee /proc/sys/net/netfilter/nf_conntrack_max

场景四：nslookup 正常但 curl 失败

这是最让人困惑的场景。根本原因：nslookup/dig 直连 DNS 服务器，而 curl 走系统 glibc 的 getaddrinfo()，受 nsswitch.conf 和 systemd-resolved 影响。

# 第1步：确认 nsswitch 配置
cat /etc/nsswitch.conf | grep hosts
# 确保包含 dns：
# hosts: files dns myhostname

# 第2步：如果用了 systemd-resolved，检查它是否正常
resolvectl status
systemctl status systemd-resolved

# 第3步：检查 nscd（Name Service Cache Daemon）是否干扰
systemctl status nscd
# nscd 的缓存可能过期但没刷新，导致返回旧数据
sudo nscd -i hosts  # 清除 hosts 缓存

场景五：resolv.conf 被自动覆盖

手动修改了 /etc/resolv.conf，但重启网络或机器后配置消失了。这是最经典的 DNS 坑。

# 先看 resolv.conf 是不是符号链接
ls -l /etc/resolv.conf

# 如果是指向 systemd-resolved 的链接：
# lrwxrwxrwx ... /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
# 不要直接改，要改 systemd-resolved 配置

# 修改 systemd-resolved 配置
sudo vim /etc/systemd/resolved.conf
# [Resolve]
# DNS=8.8.8.8 1.1.1.1
# FallbackDNS=8.8.4.4
# Domains=example.com

# 重启服务使配置生效
sudo systemctl restart systemd-resolved

如果是 NetworkManager 接管的系统：

# 查看当前连接
nmcli connection show

# 修改 DNS 配置
nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"
nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes

# 重启连接使配置生效
nmcli connection down "Wired connection 1" && nmcli connection up "Wired connection 1"

如果是 DHCP 动态获取的：

# 防止 DHCP 覆盖 DNS 配置
# 在 /etc/dhcp/dhclient.conf 中添加：
# prepend domain-name-servers 8.8.8.8 1.1.1.1;
# 或者完全覆盖：
# supersede domain-name-servers 8.8.8.8 1.1.1.1;

生产环境 DNS 配置最佳实践

服务器 DNS 配置建议

# /etc/resolv.conf 推荐配置（非 systemd-resolved 环境）
nameserver 8.8.8.8
nameserver 1.1.1.1
search internal.example.com
options timeout:2 attempts:3 rotate

# timeout:2     → 2 秒超时，不要等默认的 5 秒
# attempts:3   → 最多重试 3 次
# rotate       → 轮询使用多个 nameserver，避免只压第一个

# /etc/systemd/resolved.conf 推荐配置（systemd-resolved 环境）
[Resolve]
DNS=8.8.8.8 1.1.1.1
FallbackDNS=8.8.4.4 9.9.9.9
Domains=example.com
DNSOverTLS=opportunistic
Cache=yes
CacheFromLocalhost=no

Kubernetes Pod DNS 配置

# 对外请求频繁的 Pod，自定义 DNS 配置避免 ndots 问题
apiVersion: v1
kind: Pod
metadata:
  name: external-api-client
spec:
  dnsPolicy: None  # 禁用默认 DNS 策略
  dnsConfig:
    nameservers:
      - 8.8.8.8
      - 1.1.1.1
    searches:
      - default.svc.cluster.local
      - svc.cluster.local
    options:
      - name: ndots
        value: "2"  # 降低 ndots 避免无谓查询
      - name: timeout
        value: "2"
      - name: attempts
        value: "3"
  containers:
    - name: app
      image: myapp:latest

DNS 监控指标

生产环境应该监控 DNS 解析的健康状态：

# Bash 脚本：DNS 健康检查（可接入 Prometheus Node Exporter textfile collector）
#!/bin/bash
# dns-health-check.sh

METRICS_FILE="/var/lib/node_exporter/textfile/dns_health.prom"

# 测试 DNS 解析延迟
for domain in "internal.example.com" "google.com" "kubernetes.default.svc"; do
    start=$(date +%s%N)
    result=$(dig +short +time=2 +tries=1 "$domain" 2>/dev/null)
    end=$(date +%s%N)
    latency_ms=$(( (end - start) / 1000000 ))
    
    if [ -n "$result" ]; then
        status=1
    else
        status=0
        latency_ms=9999
    fi
    
    # 生成 metric（域名中的特殊字符替换为下划线）
    safe_domain=$(echo "$domain" | tr '.' '_')
    echo "dns_resolve_success{domain=\"${safe_domain}\"} ${status}" >> "$METRICS_FILE"
    echo "dns_resolve_latency_ms{domain=\"${safe_domain}\"} ${latency_ms}" >> "$METRICS_FILE"
done

DNS 缓存管理

# systemd-resolved 清缓存
resolvectl flush-caches

# nscd 清缓存
sudo nscd -i hosts

# dnsmasq 清缓存
sudo systemctl restart dnsmasq

# BIND 清缓存
sudo rndc flush

缓存策略建议：服务器建议开启 DNS 缓存（systemd-resolved 默认已开启），TTL 遵循上游 DNS 的设定。不要把缓存 TTL 调太大，否则域名变更后迟迟不生效。我见过有人把缓存 TTL 设成 24 小时，结果 DNS 切换后半个机房的应用还在连旧 IP，排查了整整一天。

DNS 排查速查表

症状	首先检查	可能原因	排查命令
域名完全解析不了	resolv.conf	nameserver 为空或错误	`dig @8.8.8.8 domain`
解析慢（卡 5 秒）	resolv.conf 第一个 nameserver	DNS 服务器不可达	`for ns in ...; do dig @$ns ...`
nslookup 正常但 curl 失败	nsswitch.conf	hosts 行缺少 dns	`cat /etc/nsswitch.conf \| grep hosts`
resolv.conf 被覆盖	是否符号链接	systemd-resolved/NetworkManager	`ls -l /etc/resolv.conf`
间歇性失败	连接跟踪/UDP 丢包	nf_conntrack 表满	`cat /proc/sys/net/netfilter/nf_conntrack_count`
K8s Pod 解析慢	ndots 配置	ndots:5 导致额外查询	检查 Pod resolv.conf
IPv6 导致慢	AAAA 查询超时	系统不支持 IPv6 但尝试 AAAA	`ip -6 addr show`
DNS 劫持	dig vs nslookup 结果	运营商 DNS 污染	`dig @8.8.8.8 vs dig @local`

排查流程图

域名解析失败
    │
    ├─ ping IP 通吗？
    │   ├─ 不通 → 网络问题，不是 DNS
    │   └─ 通 ↓
    │
    ├─ dig @8.8.8.8 domain 成功吗？
    │   ├─ 成功 → 本地配置问题
    │   │   ├─ 检查 /etc/resolv.conf
    │   │   ├─ 检查 /etc/nsswitch.conf
    │   │   └─ 检查 systemd-resolved
    │   └─ 失败 → DNS 服务器或网络问题
    │       ├─ ping DNS 服务器
    │       ├─ 检查防火墙 UDP 53
    │       └─ tcpdump 抓包确认
    │
    └─ 间歇性问题
        ├─ 检查 nf_conntrack
        ├─ 检查 DNS 服务器负载
        └─ 持续监控记录失败时间

总结

DNS 排查的核心是理解解析链路。整条链路是：应用 → glibc → nsswitch → hosts/缓存/DNS → resolv.conf → nameserver。每个环节都可能出问题，排查时顺着链路逐段排除。

几个实战经验总结：

dig 和 nslookup 结果对比是第一手段：如果 dig 成功但 nslookup 失败（或反过来），立刻锁定是本地解析器还是 DNS 服务器的问题
systemd-resolved 是双刃剑：它提供了缓存和灵活配置，但排查时多一层中间人。生产环境如果你不需要它的特性，可以考虑直接用传统 resolv.conf 模式，简单粗暴但好排查
resolv.conf 的 nameserver 顺序很重要：第一个不可达会拖慢所有查询。加 options timeout:2 把超时从 5 秒降到 2 秒，加 rotate 轮询分担压力
K8s 的 ndots:5 是个巨坑：对外请求频繁的 Pod 一定要自定义 dnsConfig 把 ndots 降下来，否则每次请求多 3-4 次无意义的 DNS 查询
排查 DNS 问题先抓包：tcpdump 是终极手段。看 DNS 包到底发出去没有、发给了谁、有没有响应。很多诡异问题抓一下包就清楚了
DNS 变更要考虑缓存：切换 DNS 服务器或修改域名解析后，记得清本地缓存。systemd-resolved 用 resolvectl flush-caches，nscd 用 nscd -i hosts

DNS 看起来简单，真出问题的时候排查链路很长。把这套工具链和排查流程记住，下次凌晨被告警吵醒的时候不至于手忙脚乱。

参考资料与致谢

本文在撰写过程中参考了以下资料，感谢原作者的贡献：

Linux DNS 故障排查与解析命令完整指南 — CSDN，dig/nslookup/host 命令用法详解
Linux 域名解析缓慢的定位流程 — php.cn，nslookup 与 dig 响应差异分析及 systemd-resolved 故障排查
Linux查看DNS配置教程 resolv.conf文件详解 — php.cn，resolv.conf 参数详解及动态管理机制分析
Linux怎么诊断DNS解析失败 — php.cn，DNS 解析失败的系统化排查方法
Linux如何排查DNS解析异常 — php.cn，dig 和 nslookup 诊断教程

概述#

Linux DNS 解析的完整链路#

解析优先级#

一次完整的 DNS 查询流程#

resolv.conf 的行为细节#

systemd-resolved：朋友还是麻烦#

排查工具链#

dig：DNS 排查的主力武器#

nslookup：快速验证的轻量工具#

host：最简洁的查询工具#

resolvectl：systemd-resolved 专用工具#

tcpdump：终极抓包手段#

常见故障场景与排查流程#

场景一：域名完全解析不了#

场景二：DNS 解析特别慢#

场景三：间歇性解析失败#

场景四：nslookup 正常但 curl 失败#

场景五：resolv.conf 被自动覆盖#

生产环境 DNS 配置最佳实践#

服务器 DNS 配置建议#

Kubernetes Pod DNS 配置#

DNS 监控指标#

DNS 缓存管理#

DNS 排查速查表#

排查流程图#

总结#

参考资料与致谢#

概述