DNS故障排查实战指南

背景与现象

DNS（Domain Name System）是互联网的基础设施之一，域名解析失败是运维工程师几乎每天都会遇到的问题。DNS 故障的现象很多样，而且迷惑性很强：

用户反馈"网站打不开"，但服务器明明在线 Ping 得通——这是典型的 DNS 解析正常但域名配置问题

浏览器显示"DNS_PROBE_FINISHED_NXDOMAIN"，但同一台服务器上curl可以拿到 IP——说明权威 DNS 返回 NXDOMAIN

移动端 App 正常，PC 端全部报网络错误——说明 DNS 缓存或 DNS 服务器不一致

部分地区用户正常，部分地区超时——说明 DNS 传播不完整或 CDN 调度问题

服务迁移后新 IP 已生效，但部分用户仍然解析到旧 IP——典型的 DNS 缓存问题

邮件发送失败，日志显示"Connection timed out"或"Host not found"——MX 记录或 A 记录缺失

微服务之间互相调用时突然出现大量Unknown host异常——内网 DNS 服务故障

ping域名时好时坏，每次解析到的 IP 都不同——CDN 智能解析或 DNS 劫持

DNS 故障排查的核心难点在于：DNS 是一个逐级缓存、多层转发、分布式协作的系统，问题的根因可能出在本地 resolver、递归 DNS、权威 DNS、域名注册商、CDN 调度等任何一个环节。而且因为 DNS 的缓存机制，同样的配置问题在不同地点和不同时间可能表现为完全不同的症状。

本文的目标是：建立一套从本地到远端、从客户端到服务器的系统化 DNS 故障排查路径，覆盖根因定位、临时修复、验证方法和预防措施。

工具准备

工具	用途	所在包
dig	DNS 详细查询（最推荐）	bind-utils
nslookup	简单 DNS 查询	内置
host	简化 DNS 查询	bind-utils
resolvectl	systemd-resolved 查询和控制	systemd
/etc/resolv.conf	本地 DNS resolver 配置	内置
systemd-resolve --statistics	DNS 缓存统计	systemd
rndc	BIND/named DNS 服务控制	bind
tcpdump	抓包分析 DNS 流量	tcpdump
whois	域名注册信息查询	whois

检查工具：

whichdig nslookup host resolvectl
dig -v
nslookup -version

第一阶段：先确认是不是 DNS 问题

1.1 用 Ping 和 nslookup 做初步区分

DNS 问题和其他网络问题的核心区别：DNS 问题只影响域名解析，IP 直连应该正常。

# 先 Ping 域名，看是否解析到 IP
ping -c 4 www.example.com

# 如果 Ping 不通，试试直接 Ping 解析到的 IP（如果有的话）
# 先用 nslookup 获取 IP
nslookup www.example.com

# 假设 nslookup 返回 93.184.216.34
ping -c 4 93.184.216.34

# 如果 IP 能 Ping 通但域名 Ping 不通，基本确定是 DNS 问题
# 如果 IP 也 Ping 不通，说明可能是网络连通性问题或服务器本身不可达

补充说明：ping本身也会做 DNS 解析。如果ping显示ping: unknown host，说明本地的域名解析完全失败。如果ping显示 IP 但端口不通（比如 HTTP 80 端口被防火墙拦截），说明域名解析是正常的，问题在应用层。

1.2 区分几类常见的 DNS 失败

nslookup或dig的输出可以直接告诉你失败类型：

nslookup www.example.com 8.8.8.8

# 类型 1：Server failed（DNS 服务器本身故障或被屏蔽）
# Server: 8.8.8.8
# Address: 8.8.8.8#53
# ** server can't find www.example.com: SERVFAIL

# 类型 2：NXDOMAIN（域名不存在或未注册）
# Server: 8.8.8.8
# Address: 8.8.8.8#53
# ** server can't find www.example.com: NXDOMAIN

# 类型 3：Connection timed out（DNS 服务器不可达）
# ;; connection timed out; no servers could be reached

# 类型 4：有响应但返回空（NOERROR 但没有 Answer，只有 Authority）
# Server: 8.8.8.8
# Address: 8.8.8.8#53
# www.example.com  canonical name = example.com.
# Name: example.com
# Address: 93.184.216.34
# （这里 www 被 CNAME 到了 example.com，最终找到了 A 记录）

快速对照表：

DNS 错误	含义	排查方向
SERVFAIL	权威 DNS 服务器内部错误	DNSSEC 验证失败、NS 服务器宕机
NXDOMAIN	域名不存在	域名过期、配置错误、未完成传播
REFUSED	查询被拒绝	ACL 配置错误、防火墙拦截
TIMEOUT	无响应	DNS 服务器不可达、网络不通
NOERROR 但空 Answer	域名有记录但不匹配查询类型	记录类型不匹配（如查 AAAA 只有 A 记录）

第二阶段：本地 DNS 解析器排查

2.1 查看本地 DNS 配置

cat /etc/resolv.conf

# 典型输出：
; generated by /usr/sbin/resolvconf, ifupdown's managed interfaces
nameserver 10.0.0.2
nameserver 8.8.8.8
search example.com
options timeout:2 attempts:3 rotate

重点关注：

nameserver：DNS 服务器 IP 地址。第一个优先（10.0.0.2），如果它不响应会自动切换到第二个（8.8.8.8）

search：搜索域。如果查询www，会自动补全为www.example.com（减少输入）

options：

timeout:2：每次 DNS 查询超时时间（默认 5 秒，可以改小加快故障检测）

attempts:3：失败重试次数（默认 2）

rotate：轮询使用 nameserver（默认只用第一个，轮询可以负载均衡）

注意：/etc/resolv.conf通常由 NetworkManager 或 dhclient 自动管理。直接修改可能在下一次网络重启后被覆盖。如果要永久修改：

# RHEL/CentOS：修改 /etc/sysconfig/network-scripts/ifcfg-eth0
# 添加或修改：
PEERDNS=no # 不让 DHCP 覆盖 resolv.conf
DNS1=8.8.8.8
DNS2=1.1.1.1

# Debian/Ubuntu：修改 /etc/network/interfaces 或通过 systemd-resolved
# systemd-resolved 配置在 /etc/systemd/resolved.conf

2.2 检查 systemd-resolved 状态

如果系统使用 systemd-resolved（Ubuntu 18.04+、CentOS 8+ 默认）：

# 查看 DNS 解析状态
resolvectl status

# 典型输出：
Global
   LLMNR setting: yes
MulticastDNS setting: yes
 DNSSEC setting: allow-downgrade
 DNSSEC supported: yes
     DNSSEC over TCP: yes
     Current DNS Server: 10.0.0.2
        DNS Servers: 10.0.0.2
              8.8.8.8
              1.1.1.1

Link ens33
   Current Scopes: DNS LLMNR/IPv4
       DNSSEC supported: yes
    DNS Servers: 10.0.0.2
          8.8.8.8
   DNS Domain: example.com

systemd-resolved 的缓存统计：

resolvectl statistics

# 典型输出：
DNSSEC supported: yes
Transaction duration: [rtt, percentile]
 50%: 1ms
 90%: 2ms
 99%: 10ms
Cache: 500 hits, 1200 misses
Cache size: 10000 entries (max 10000)
Current cache size: 1234 entries
Negative cache size: 234 entries

Cache hits：缓存命中数，缓存正常工作

Cache misses：缓存未命中数，每次未命中都要向外部 DNS 查询

如果看到大量 FAILURE 计数，说明 DNS 查询大量失败

2.3 测试指定的 DNS 服务器

绕过本地 resolver，直接查询指定的公共 DNS 服务器：

# 用 Google DNS 查询
dig @8.8.8.8 www.example.com +short

# 用 Cloudflare DNS 查询
dig @1.1.1.1 www.example.com +short

# 用阿里的 DNS 查询（国内环境常用）
dig @223.5.5.5 www.example.com +short

# 指定类型查询（A、AAAA、MX、NS、TXT）
dig @8.8.8.8 example.com MX +short
dig @8.8.8.8 example.com NS +short
dig @8.8.8.8 example.com TXT +short

关键判断原则：

如果@8.8.8.8查询正常，但本地 DNS（/etc/resolv.conf中的 nameserver）查询失败，说明问题在本地 DNS resolver 配置或网络路径

如果@8.8.8.8也失败，说明问题在权威 DNS 服务器或网络本身

2.4 追踪完整的 DNS 解析路径

用dig的+trace选项可以看到完整的递归解析过程：

dig @8.8.8.8 www.example.com +trace

这会输出从根服务器（.）→ TLD 服务器（.com）→ 权威 DNS 的完整路径：

.     518400 IN NS a.root-servers.net.
.     518400 IN NS b.root-servers.net.
;; Received 528 bytes

com.    172800 IN NS a.gtld-servers.net.
com.    172800 IN NS b.gtld-servers.net.
;; Received 548 bytes

example.com.  172800 IN NS a.iana-servers.net.
example.com.  172800 IN NS b.iana-servers.net.
;; Received 89 bytes

www.example.com. 300 IN A 93.184.216.34

如果在 TLD 服务器那一步卡住（长时间无响应），说明 DNS 传播或 TLD 服务器配置有问题。

2.5 查看 DNS 查询的详细信息

dig @8.8.8.8 www.example.com +all

-all会输出 DNS 消息的完整头部：

;; QUESTION SECTION:
;www.example.com.   IN A

;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34

;; AUTHORITY SECTION:
example.com.   172800 IN NS a.iana-servers.net.
example.com.   172800 IN NS b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 3600 IN A 199.43.135.53
b.iana-servers.net. 3600 IN A 199.43.135.53

;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon May 25 1000 CST 2026
;; MSG SIZE rcvd: 156

重点检查：

flags中的AA（Authoritative Answer）：如果查询结果没有 AA，说明是缓存响应，不是权威答案

ANSWER SECTION是否为空：如果为空且不是 NXDOMAIN，可能是记录类型不匹配

Query time：DNS 查询耗时，超过 100ms 说明 DNS 服务器响应慢

MSG SIZE rcvd：响应包大小。如果超过 512 字节，UDP 可能会被截断（需要 TCP 重试）

第三阶段：权威 DNS 服务器排查

3.1 检查域名的 NS 记录是否正确

# 查看域名的 NS 记录
dig example.com NS

# 验证权威 DNS 服务器的 A 记录（NS 服务器自己的 IP）
dig @8.8.8.8 ns1.example.com A
dig @8.8.8.8 ns2.example.com A

# 对比注册商处配置的 NS 服务器地址
whois example.com | grep -E"Name Server|NS-Name"

这一步检查：域名注册商处配置的 NS 服务器是否与 DNS 服务商处一致。如果不一致，DNS 查询就会打到错误的服务器。

常见错误：

域名注册商处写的是ns1.example.com，但ns1.example.com的 A 记录（NS 服务器的 IP）没有正确配置

域名迁移时 NS 记录更新了，但旧 NS 服务器还没下线，新 NS 服务器还没完全生效

3.2 检查域名是否过期或被删除

如果dig返回NXDOMAIN，但你确认域名是有效的：

whois example.com | grep -E"Domain Status|Expir|Domain Expir|Registrar|Registrant"

# 常见的问题状态：
# Domain Status: clientHold (Registrar clientHold - 注册商暂停)
# Domain Status: serverHold (Registrar serverHold - 注册商暂停)
# Domain Status: redemptionPeriod (域名删除中，45 天后才能重新注册)
# Domain Status: inactive (没有注册或已过期)
# Domain Status: pendingDelete (等待删除，通常 5 天后可以重新注册)

如果whois显示clientHold或serverHold，说明域名在注册商层面被暂停了，DNS 查询会失败。这个问题只能联系域名注册商解决，DNS 配置本身没有问题。

3.3 检查 DNSSEC 是否配置错误

DNSSEC 验证失败会导致SERVFAIL：

# 用 dig 关闭 DNSSEC 验证，看结果是否不同
dig @8.8.8.8 www.example.com +dnssec +noedns

# 如果关闭 DNSSEC 后解析正常，说明 DNSSEC 签名验证失败

# 检查域名的 DS 记录（DNSSEC 签名）
dig @8.8.8.8 example.com DS

# 检查 DNSKEY 记录（公钥）
dig @8.8.8.8 example.com DNSKEY

DNSSEC 验证失败的常见原因：

域名启用了 DNSSEC，但域名注册商没有配置 DS 记录（DS 是连接 DNS 和 DNSSEC 的桥梁）

DNSSEC 已关闭但 DNS 服务器仍然发送了 RRSIG（DNSSEC 签名记录），导致验证失败

KSK（Key Signing Key）轮转时，新旧密钥过渡没有正确配置

DNSSEC 问题修复：

如果域名不需要 DNSSEC，最快的方法是暂时关闭 DNSSEC（到域名注册商控制台关闭 DNSSEC 签名，DS 记录删除），然后用公共 DNS 验证。

3.4 检查 SOA 记录和刷新时间

SOA 记录包含域名管理信息和缓存刷新策略：

dig example.com SOA

# 关注这些字段：
# serial：序列号，用于判断 DNS 数据是否更新
# refresh：Secondary DNS 多久查一次更新（单位：秒）
# retry：refresh 失败后多久重试
# expire：Secondary DNS 多久放弃使用旧数据
# minimum：TTL 下限，缓存多久可以认为数据无效

典型的 SOA 记录：

example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
        2026052501 ; Serial (YYYYMMDDNN 格式)
        7200     ; Refresh (2 hours)
        3600     ; Retry (1 hour)
        1209600   ; Expire (14 days)
        86400 )   ; Minimum TTL (1 day)

serial 的重要性：域名迁移后，如果 serial 没有增加，Secondary DNS（Slave）不会知道数据已更新，会继续推送旧数据。迁移前必须确认 serial 增加了。

TTL 的实际影响：SOA 的minimum值（也叫 Minimum TTL）是权威答案的最短缓存时间。DNS 记录本身的 TTL（如 A 记录的 300 秒）不能低于这个值。如果域名迁移前将 A 记录 TTL 降到 300 秒，但 SOA minimum 是 86400 秒，resolver 仍然会缓存 86400 秒。

3.5 检查 DNS 记录传播

DNS 修改后，不同 DNS 服务器在不同时间收到更新，导致部分用户看到新记录、部分用户看到旧记录。

# 用多个不同的 DNS 服务器查询，对比结果
fornsin8.8.8.8 1.1.1.1 223.5.5.5 114.114.114.114;do
 echo-n"DNS$ns: "
  dig +short @$nswww.example.com
done

# 用全球 DNS 传播查询工具（网页或 API）
# https://www.whatsmydns.net/#A/www.example.com
# 这个工具会从全球多个节点查询，同一时间看到不同结果，说明传播未完成

如果不同 DNS 服务器返回不同结果，说明 DNS 传播还未完成。大多数 DNS 服务商的全球传播在 10 分钟内完成，但 DNSSEC 配置的 DS 记录传播可能需要 24~48 小时。

第四阶段：常见根因与修复方案

根因一：本地 DNS 缓存导致解析到旧 IP

典型场景：服务迁移到新 IP 后，部分用户仍然解析到旧 IP，导致 502/504 错误。这是 DNS 缓存问题中最常见的一种。

判断方法：

# 在服务器侧用权威 DNS 查询
dig @ns1.example.com www.example.com +short

# 在用户侧（你的测试环境）用本地 DNS 查询
nslookup www.example.com 10.0.0.2 # 用本地 DNS 服务器

# 用公共 DNS 查询
dig @8.8.8.8 www.example.com +short
dig @1.1.1.1 www.example.com +short

# 如果本地 DNS 返回的 IP 与权威 DNS 不同，说明本地缓存了旧记录

修复方案：

方案一：清除本地 DNS 缓存

# 清除 systemd-resolved 缓存（Ubuntu、CentOS 8+）
sudo systemd-resolve --flush-caches

# 验证清除
resolvectl statistics | grep"Cache size"

# 如果 DNS 服务器是 BIND/named，清除其缓存
sudo rndc flush

# 如果 DNS 服务器是 dnsmasq，重启服务
sudo systemctl restart dnsmasq

# 如果用的是 Nscd（Name Service Cache Daemon），清除缓存
sudo systemctl restart nscd

方案二：降低域名 TTL（在迁移前操作）

在迁移前 48 小时，将域名的 DNS 记录 TTL 降到 300 秒（5 分钟）：

# 迁移前修改 DNS 记录的 TTL
# 具体操作取决于 DNS 服务商控制台（阿里云 DNS、腾讯云 DNSPod、Cloudflare 等）
# 将 www.example.com 的 A 记录 TTL 从 3600 改为 300

迁移完成后，确认新 IP 生效，再将 TTL 恢复到 3600 秒。

方案三：IP 层平滑迁移

如果不能等待缓存过期（业务紧急），可以在 Nginx/HAProxy/keepalived 侧做 IP 层的平滑切换：

# 阶段 1：旧 IP 和新 IP 同时指向同一服务（Nginx upstream 中配置两个 server）
# 阶段 2：验证新 IP 流量正常后，逐步从 upstream 中移除旧 IP
# 阶段 3：旧 IP 正式下线

根因二：DNS 记录配置错误

典型场景：新增 DNS 记录时拼写错误，或者记录类型错误（A 记录写成了 CNAME）。

常见错误类型：

错误 1：A 记录指向内网 IP

# 如果 A 记录指向 10.0.0.1、192.168.x.x 等内网地址，外网用户无法访问
dig @8.8.8.8 api.example.com A

# 正确做法：外网域名的 A 记录必须指向公网 IP
# 检查 IP 是否为公网 IP（公网 IP 通常不在以下范围内）：
# 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8

错误 2：CNAME 和 A 记录混用

根域名（example.com）不能设置 CNAME（RFC 1032 规定），只能设置 A 记录。子域名（www.example.com）可以设置 CNAME 指向另一个域名：

# 正确的根域名配置（只能 A 记录）
example.com. 300 IN A 93.184.216.34

# 正确的子域名配置（可以是 CNAME）
www.example.com. 300 IN CNAME example.com.
# 或者直接 A 记录
www.example.com. 300 IN A 93.184.216.34

错误 3：MX 记录指向主机名而非 IP

MX 记录的值应该是邮件交换服务器的主机名，不是 IP：

# 错误的 MX 配置
example.com. 300 IN MX 10 93.184.216.34

# 正确的 MX 配置（主机名，不是 IP）
example.com. 300 IN MX 10 mail.example.com.
mail.example.com. 300 IN A 93.184.216.34

错误 4：TTL 设为 0

某些老旧 DNS 解析器对 TTL=0 的处理不符合标准，可能导致缓存永久有效或完全不缓存。

错误 5：多条 A 记录权重分配不均

如果有多条 A 记录（用于负载均衡），确保每条记录都是正确的 IP，且数量与预期一致。

根因三：DNS 传播延迟

典型场景：在域名注册商或 DNS 服务商修改了 DNS 记录，但部分用户仍然得到旧记录。

判断方法：

# 逐一查询所有 NS 服务器，看是否返回一致的答案
fornsin$(dig example.com NS +short);do
 echo"NS:$ns"
  dig @$nswww.example.com +short
 echo"---"
done

如果某个 NS 服务器返回的 IP 与其他 NS 不同，说明该 NS 服务器还没有收到更新。

修复方案：

确认修改是否已经同步到所有 NS 服务器（SOA serial 是否已更新）

确认 DNS 服务商的控制台显示"配置已生效"

如果使用了 DNSSEC，确认 DS 记录已正确配置

如果超过 48 小时仍有部分用户解析到旧 IP，联系域名注册商确认 DNS 服务是否正常工作

根因四：NS 服务器不可用

典型场景：域名注册商配置的 NS 服务器 IP 不正确，或者 NS 服务器本身宕机。

# 查看域名的 NS 记录
dig example.com NS

# 逐一查询每个 NS 服务器，看是否响应
fornsin$(dig example.com NS +short);do
 echo-n"Testing$ns(port 53): "
  nc -vzu$ns53 2>&1 | head -1
done

# 查看权威 DNS 是否一致
dig @ns1.example.com www.example.com +short
dig @ns2.example.com www.example.com +short

常见 NS 服务器问题：

NS 服务器地址配置错误：注册商处填写的 NS 服务器名称在 DNS 服务商处没有配置 A 记录（NS 服务器自己也需要 IP 才能响应）

NS 服务器防火墙拦截：DNS 服务器的 53 端口（UDP/TCP）被防火墙拦截

NS 服务器过载：DNS 查询量太大，NS 服务器拒绝响应（常见于 DDoS 攻击期间）

修复方案：

# 如果使用的是注册商默认 NS（如阿里云默认的 dns*.hichina.com）
# 问题通常是注册商控制台的 NS 配置没有正确同步到 TLD 服务器
# 解决方法：重新在注册商处保存 NS 配置，或联系注册商技术支持

# 如果使用的是第三方 DNS 服务（Cloudflare、阿里云 DNS）
# 在 DNS 服务商控制台确认 NS 地址配置正确
# 在域名注册商处确认 NS 服务器名称与 DNS 服务商提供的一致

根因五：网络层阻止 DNS（UDP/53）

典型场景：DNS 查询在特定网络环境下失败（如公司防火墙、容器网络、VPN 环境）。

判断方法：

# 确认 DNS 使用 UDP 53 端口
nc -vzu 8.8.8.8 53

# 如果 UDP 不通，试试 TCP（DNS 在 UDP 截断时会降级到 TCP）
dig @8.8.8.8 +tcp www.example.com

# 如果 TCP 能通但 UDP 不通，说明是 UDP 53 被防火墙拦截
# DNS 规范要求所有 DNS 服务器必须支持 TCP 53

# 抓包看 DNS 包是否发出和收到
sudo tcpdump -i eth0 -n port 53 -c 20

# 触发 DNS 查询
dig @8.8.8.8 www.example.com

# 停止 tcpdump，看输出
# 如果能看到发出的 DNS 请求但没有响应，很可能是防火墙拦截
# 如果连请求都没发出，说明是路由问题

DNS over HTTPS（DoH）和 DNS over TLS（DoT）绕过方案：

如果 UDP 53 被封锁，可以考虑使用加密 DNS：

# 使用 Cloudflare 的 DNS over HTTPS（DoH）
dig @1.1.1.1 www.example.com +https

# 使用 Google 的 DNS over TLS（DoT）
# 需要在 systemd-resolved 中配置
# 编辑 /etc/systemd/resolved.conf
# DNS=1.1.1.1
# DNSOverTLS=yes
# 然后重启
sudo systemctl restart systemd-resolved

根因六：搜索引擎收录了旧 IP

有时候 DNS 本身没有问题，但搜索引擎（百度、Google）的蜘蛛仍然缓存了旧 IP。

判断方法：

直接输入域名显示旧 IP，但用dig查询已经得到新 IP

在不同地区、不同运营商下测试，部分正常部分异常

Ping 域名得到的 IP 与dig结果一致，但实际访问通过浏览器却连到了旧 IP

解决方法：

在百度 Search Console 中提交"抓取"→"清除缓存"请求

在 Google Search Console 中提交"移除网址"请求

等待搜索引擎重新抓取（通常 24~72 小时）

第五阶段：进阶排查工具

5.1 用 tcpdump 抓包看 DNS 交互细节

# 抓取 DNS 请求和响应包（UDP 53 端口）
sudo tcpdump -i eth0 -n port 53 -w /tmp/dns_capture.pcap

# 在另一个终端触发 DNS 查询
dig @8.8.8.8 www.example.com

# 停止 tcpdump（Ctrl+C）

# 分析抓包文件
tcpdump -r /tmp/dns_capture.pcap -n -v | head -50

# 用 tshark（Wireshark 命令行版）直接看 DNS 解析过程
sudo tshark -i eth0 -f"port 53"-Y"dns.flags.response == 1"-T fields 
 -e dns.qry.name -e dns.a -e dns.rcode -e dns.flags.rcode

在抓包中重点关注：

请求是否发出（source IP 是否正确）

响应是否收到（destination IP 是否正确）

DNS 响应码（RCODE）：0=NOERROR，2=SERVFAIL，3=NXDOMAIN

如果有大量重传（retransmission），说明网络丢包或 DNS 服务器响应慢

DNS 请求和响应之间的时间差（如果超过 1 秒，说明 DNS 服务器处理慢或网络延迟高）

5.2 检查 DNS 服务端日志

如果自己搭建了 DNS 服务器（BIND/named），查看日志中的错误：

# BIND/named 日志（位置因发行版而异）
sudo journalctl -u named -n 50 --no-pager

# 查看 BIND 查询日志（需要开启 query logging）
sudo rndc status
sudo rndc querylog on

# 查看查询日志位置
grep"query logging"/etc/named.conf

# tail 查看实时日志
sudo tail -f /var/log/named/query.log

# 如果 DNS 服务崩溃或被限流，日志中会有明确的错误信息
# 常见错误：
# "too many queries" - 被限流，需要增加 max-cache-size 或启用 RPZ
# "network unreachable" - 递归查询时网络不通
# "SERVFAIL" - DNSSEC 验证失败或上级 NS 不响应

5.3 DNS 拨测工具

如果需要在全国或全球多地点测试 DNS 解析：

# DNSPod 的 DNS 诊断（国内常用）
# https://www.dnspod.cn/services/dns%20%E6%A3%80%E6%B5%8B

# 阿里云 DNS 解析检测（国内常用）
# https://www.alidns.com/diagnose

# What's My DNS（全球 DNS 传播查询）
# https://www.whatsmydns.net/#A/www.example.com

# 使用 curl 调用 API 做自动化拨测
curl -s"https://www.dnschecker.com/?query=www.example.com&rtype=A"| grep -oE'[0-9]+.[0-9]+.[0-9]+.[0-9]+'

这些工具可以同时从多个地点发起 DNS 查询，帮助判断是全局性问题还是特定区域问题。

第六阶段：修复后的验证

修复完成后，必须完整验证，不能仅凭一次查询成功就认为问题解决了：

# 1. 在权威 DNS 服务器验证（直接查权威，不走缓存）
dig @ns1.example.com www.example.com +short

# 2. 在多个公共 DNS 验证（等待缓存刷新后）
dig @8.8.8.8 www.example.com +short
dig @1.1.1.1 www.example.com +short
dig @223.5.5.5 www.example.com +short

# 3. 在本地 DNS 验证（如果有自建 resolver）
dig @10.0.0.2 www.example.com +short

# 4. 用不同工具交叉验证
nslookup www.example.com
host www.example.com
resolvectl query www.example.com

# 5. 确认所有 NS 服务器返回一致结果
fornsin$(dig example.com NS +short);do
 echo-n"NS$ns: "
  dig @$nswww.example.com +short
done

# 6. 如果是 Web 服务，验证 HTTP 可达（同时验证 DNS 解析正确和应用正常）
curl -I https://www.example.com 
 -w"
HTTP Code: %{http_code}
DNS Lookup: %{time_namelookup}s
Total: %{time_total}s
"
 --connect-timeout 5 --max-time 10

# 7. 如果是邮件服务，验证 MX 记录和 SMTP 连通性
dig @8.8.8.8 example.com MX +short
nc -vz mail.example.com 25

# 8. 验证 DNSSEC（如果启用了）
dig @8.8.8.8 www.example.com +dnssec +short

生产环境 DNS 操作规范

DNS 是生产环境的"总开关"，错误配置可能导致全局不可用。以下是操作规范：

改 DNS 前必须做的准备

备份当前配置：在域名注册商控制台截图当前所有 DNS 记录，或导出 Zone 文件（如果是 BIND 格式）

# 如果用的是 BIND，导出 zone 文件
sudo rndc zonestatus example.com
sudo named-checkzone example.com /var/named/zones/example.com.zone

确认操作时间窗口：选择业务低峰期（通常是深夜或凌晨）。DNS 变更对全球生效可能需要数小时

确认回滚方案：记录原始配置，准备一键回滚。最好在操作前准备回滚脚本

通知相关团队：变更 DNS 可能影响多个业务，提前通知

DNS 修改的风险控制

先改测试记录再改正式记录：先添加一条test.example.com验证配置正确，再改主记录

# 先验证 test 记录是否正确生效
dig @8.8.8.8 test.example.com A

先加后删原则：新 IP 确认生效后，再下线旧 IP，避免服务中断

# 阶段 1：新增新 IP，保持旧 IP 同时生效
# www.example.com A 旧IP
# www.example.com A 新IP

# 阶段 2：确认新 IP 流量正常后，移除旧 IP
# www.example.com A 新IP

TTL 设置策略：

正常运营：TTL = 3600（1 小时），平衡缓存效率和变化响应速度

迁移前 48 小时：TTL = 300（5 分钟），确保快速切换

迁移完成稳定后：逐步恢复到 TTL = 3600

# 迁移前脚本思路（伪代码）
# 1. 记录当前 DNS 记录
# current_records = get_dns_records("www.example.com")

# 2. 将 TTL 降为 300
# set_dns_ttl("www.example.com", 300)

# 3. 等待 48 小时（让全球缓存过期）
# time.sleep(48 * 3600)

# 4. 修改 IP 地址
# set_dns_a_record("www.example.com", "新IP")

# 5. 等待新记录传播（观察全球 DNS 检测工具）
# poll_dns_propagation("www.example.com")

# 6. 确认生效后，将 TTL 恢复
# set_dns_ttl("www.example.com", 3600)

禁止在生产 DNS 上做的事情

禁止在不清楚影响范围的情况下删除 NS 记录

禁止将 TTL 设为 0（除非明确知道所有 resolver 都正确处理）

禁止在多个 NS 服务器之间配置不同的解析结果（必须保持一致）

禁止用 Excel 或文本编辑器手动编辑 Zone 文件后直接覆盖（使用 rndc 或 API 操作，避免格式错误）

禁止一次性修改大量 DNS 记录（分批修改，每批验证后再修改下一批）

故障复盘模板

【故障复盘】DNS 解析故障

故障域名：
发现时间：
影响范围（哪些用户、哪些服务）：
持续时长：

故障现象：
- dig/nslookup 结果：
- HTTP 访问结果：
- 不同 DNS 服务器查询结果对比：

排查过程：
1. [命令] 确认问题类型：[NXDOMAIN / SERVFAIL / 超时 / IP 不一致]
2. [命令] 排除本地问题：[测试结果，如 @8.8.8.8 查询正常]
3. [命令] 检查权威 DNS：[测试结果]
4. [命令] 检查 whois 域名状态：[状态结果]
5. [命令] 检查 DNS 传播：[各 NS 查询结果对比]
6. [命令] 检查 DNSSEC：[测试结果]

根因：[具体说明]

修复措施：
1. [具体操作内容]
2. [具体操作内容]

验证结果：
- 权威 DNS 验证：
- 公共 DNS 验证：
- HTTP 访问验证：

预防措施：
1. 常态化 DNS 健康检查（监控 NS 可用性、SOA serial 变化）
2. 域名到期前提醒
3. DNSSEC 到期前提醒
4. ...

CDN 场景下的 DNS 特殊问题

在使用 CDN（内容分发网络）时，DNS 解析不仅是域名到 IP 的映射，还要承担 CDN 调度职责——根据用户地理位置、网络状况、CDN 节点负载等返回最优节点 IP。CDN 相关的 DNS 问题有其特殊性。

CDN 调度失败导致部分用户访问慢

典型场景：用户反馈网站加载极慢，但 DNS 解析是正常的（dig能查到 IP）。实际问题是 CDN 返回的节点 IP 距离用户很远，或者节点本身不可用。

判断方法：

# 对比不同地点的解析结果
# 从北京DNS查询
dig @ns.bjtelecom.net www.example.com +short

# 从上海DNS查询
dig @ns.shtelecom.com www.example.com +short

# 从海外DNS查询
dig @8.8.8.8 www.example.com +short

# 如果使用 Cloudflare，查看节点 IP
dig @1.1.1.1 www.example.com +short
# Cloudflare 的 IP 通常在 104.x.x.x ~ 172.x.x.x 范围

# 如果使用阿里云 CDN，查看调度结果
dig @8.8.8.8 www.example.com +short
# 阿里云 CDN 节点 IP 通常在阿里云公网 IP 段

# 对比 CDN 控制台显示的节点 IP 列表
# 在 CDN 控制台查看域名加速域名的源站配置和 CNAME 配置

CDN 常见配置错误：

CNAME 配置错误：域名的 CNAME 没有正确指向 CDN 厂商的加速域名，导致请求绕过了 CDN 直连源站

# 正确的 CDN CNAME 配置示例
# www.example.com CNAME www.example.com.w.kunluncan.com
# （每个 CDN 厂商的 CNAME 后缀不同）

源站配置错误：CDN 回源时指向了错误的 IP 或域名

# 在 CDN 控制台查看源站配置
# 确保源站 IP 可达
curl -I http://源站IP -H"Host: www.example.com"

DNSSEC 深度排查

DNSSEC 是 DNS 安全扩展，通过数字签名确保 DNS 响应来自权威服务器且未被篡改。DNSSEC 配置错误是导致SERVFAIL的常见原因。

DNSSEC 验证失败的完整排查步骤：

# 步骤 1：确认域名是否启用了 DNSSEC
dig @8.8.8.8 example.com DNSKEY +short
# 如果返回空，说明域名没有 DNSSEC 密钥（可能没有启用）

# 步骤 2：查看 DS 记录（由注册商持有，是 DNSSEC 的入口）
dig @8.8.8.8 example.com DS +short

# 步骤 3：确认 DNSSEC 签名是否正确（验证 RRSIG）
dig @8.8.8.8 +dnssec www.example.com A
# 如果有 RRSIG 记录，说明 DNSSEC 签名存在

# 步骤 4：手动验证 DNSSEC（用 drill 或 delv）
# drill（Alpine/BSD 系统自带）
drill -D www.example.com
# 或用 delv（Bind-utils）
delv -d www.example.com

# 步骤 5：检查根域名的信任链（根 DNSKEY 是否可信）
# 根 DNSKEY 是预置在 resolver 中的，通常不需要手动检查
# 但某些自建 resolver 可能没有预置根 DNSKEY

# 检查 BIND 的 trusted-keys（DNSSEC 信任锚点）
grep -r"trusted-keys"/etc/named.conf

DNSSEC 问题修复：

如果确认是 DNSSEC 问题导致SERVFAIL，最快的方法是暂时关闭 DNSSEC（在域名注册商控制台操作），确认业务恢复后再修复 DNSSEC 配置。

DNSSEC 修复的完整流程：

# 1. 在 DNS 服务商处获取新的 DS 记录（如果是在 Cloudflare，使用其自动 DS 管理）
# 2. 在域名注册商处更新 DS 记录
# 3. 等待 DS 记录传播（通常 24-48 小时）
# 4. 用 delv 或 drill 验证 DNSSEC 链完整

内网 DNS（BIND）自建 DNS 的维护

在企业内部网络中，通常会搭建自建的 DNS 服务器来处理内网域名解析。这类 DNS 的故障排查和公共 DNS 有所不同。

自建 BIND DNS 常见问题：

# 检查 named 服务状态
sudo systemctl status named
sudo rndc status

# 查看 BIND 日志（通常在 /var/log/messages 或 /var/log/named/named.log）
sudo journalctl -u named -n 100 --no-pager | grep -E"error|warning|fail"

# 检查 zone 文件语法
sudo named-checkzone example.com /var/named/zones/example.com.zone

# 检查 named.conf 语法
sudo named-checkconf /etc/named.conf

# 如果 zone 文件更新了但解析不到，执行 rndc reload
sudo rndc reload example.com

# 查看 BIND 的查询日志（调试用，临时开启）
sudo rndc querylog on
tail -f /var/log/named/query.log

内网 DNS 的递归查询配置：

# /etc/named.conf 中的递归查询配置
# 允许哪些客户端做递归查询（安全控制）
allow-query { 10.0.0.0/8; 127.0.0.1; };

# 是否允许递归查询（关闭后只能做权威查询）
recursion yes;

# 转发配置（不自己递归，而是转发到上游 DNS）
forwarders { 8.8.8.8; 223.5.5.5; };
forward first;

内网 DNS 的常见故障：

内网域名解析正常，公网域名解析失败：通常是 forwarders 配置缺失或上游 DNS 不可达

# 测试转发是否正常
dig @内网DNS地址 www.baidu.com

特定内网域名解析失败：zone 配置错误或 zone 文件语法错误

# 检查 zone 配置
sudo named-checkconf /etc/named.conf

# 重载配置
sudo rndc reload

DNS 服务正常但部分客户端无法解析：通常是防火墙或 ACL 配置问题

# 确认 DNS 53 端口在所有网段可达
nc -vzu 内网DNS地址 53

总结

DNS 故障排查的核心路径：

Ping/IP 直连（区分 DNS 问题和其他网络问题）
→ dig/nslookup（获取详细信息：类型、错误码、回答内容）
→ 切不同 DNS 服务器查询（区分本地/权威问题）
→ dig +trace（追踪递归解析路径）
→ whois 检查域名状态（clientHold / 过期的判断标准）
→ tcpdump 抓包（确认包是否发出和收到）
→ 对应根因修复（缓存 / 配置错误 / 传播延迟 / 网络拦截）
→ 多方验证（权威 DNS + 公共 DNS + 本地 DNS）

常见 DNS 失败类型的快速对照：

错误类型	含义	常见根因	首要排查命令
NXDOMAIN	域名不存在	域名过期、配置错误、未完成 DNS 传播	whois 域名状态
SERVFAIL	DNS 服务器内部错误	DNSSEC 验证失败、DNS 服务器故障	关闭 DNSSEC 再试
REFUSED	查询被拒绝	DNS ACL 配置错误、防火墙拦截	tcpdump 确认包收到
TIMEOUT	DNS 服务器无响应	DNS 服务器宕机、网络不通、防火墙拦截 UDP/53	nc -vzu 53
IP 不一致	多地查询结果不同	DNS 传播未完成、多个 NS 配置不一致	逐一查询各 NS
部分用户异常	特定地区/运营商问题	DNS 传播未完成、CDN 调度问题	多地拨测工具

DNS 问题排查的关键是分层定位：本地 DNS resolver 缓存问题、权威 DNS 配置问题、域名注册商层面问题（域名 hold、NS 配置错误）、DNSSEC 签名验证失败、网络层阻断。只要方法正确，大多数 DNS 问题可以在 5~15 分钟内完成根因定位。