dns-servfail

DNS 返回 SERVFAIL 的定位与修复

现象

dig 的返回状态是 status: SERVFAIL，nslookup 报 server can't find 或 SERVFAIL，应用侧表现为 Temporary failure in name resolution、server misbehaving 或解析超时。SERVFAIL 不是“域名不存在”，它表示解析器无法完成这次查询：可能是权威服务器不可达、委派配置错误、DNSSEC 校验失败、传输受阻，或解析器自身资源不足。

要和 NXDOMAIN 区分开：NXDOMAIN 是权威服务器明确回答“这个名字不存在”，通常不需要继续排查链路；SERVFAIL 则是没有拿到可用答案，必须继续定位。SERVFAIL 也可能来自缓存中的旧失败结果，失败缓存有效期内重复查询会持续失败，必要时清缓存后再验证，但清缓存不是根因修复。

快速定位

先确认影响范围，再逐层查询：

dig example.com
dig +short example.com
dig @<resolver> example.com
dig @8.8.8.8 example.com
dig +trace example.com
dig NS example.com
dig SOA example.com
dig +norecurse @<auth-ns> example.com

检查 DNSSEC 和传输：

dig +dnssec example.com
dig +cd example.com
dig +tcp example.com
dig +bufsize=512 example.com

dig +dnssec 仍然失败、dig +cd 能成功，通常说明 DNSSEC 验证有问题。+tcp 成功、UDP 失败，常见于大响应被丢或 UDP 53 受限。如果所有域名都 SERVFAIL，先检查 /etc/resolv.conf 和本机解析器；如果只有某个域失败，再查该域的委派、权威服务和 DNSSEC。

本机解析器：

resolvectl status
cat /etc/resolv.conf
journalctl -u systemd-resolved --since '30 min ago'

Kubernetes 集群内：

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl get svc,endpoints -n kube-system kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100
kubectl run -it --rm dnstest --image=<debug-image> --restart=Never \
  -- nslookup kubernetes.default

集群内只有内部域名失败、外部域名正常，重点查 CoreDNS 的 kubernetes 插件和 API 连通性；只有外部域名失败，重点查 forward 上游和出站网络。

常见根因

1. DNSSEC 校验失败：签名过期、DNSKEY/DS 缺失或不匹配、算法不受支持。
2. 权威服务器不可达、超时，或委派指向了并不权威的服务器（lame delegation）。
3. 父区缺少 NS 记录的 glue 地址，解析器无法到达权威服务器。
4. Zone 配置错误：CNAME 循环、SOA 异常、记录格式错误或序列号问题。
5. 转发器故障、转发链形成循环，或递归深度超过限制。
6. 防火墙拦截 UDP/TCP 53，EDNS 大包被丢弃，TCP 回退也不可用。
7. 解析器文件描述符、内存或查询速率达到上限，缓存损坏或遭受限流。
8. CoreDNS 的 forward 上游不可达、并发上限触发、loop 插件检测到循环。
9. CoreDNS 的 kubernetes 插件无法访问 API server，集群域名查询失败。
10. NetworkPolicy 或节点防火墙拦截 Pod 到 CoreDNS、CoreDNS 到上游的 53 端口。
11. 拆分视图或条件转发配置错误，内外部域名被送到了错误的上游。
12. 域名刚变更，缓存仍保存旧的失败结果，或失败缓存未过期导致修复后短时间仍失败。
13. 权威服务器只监听部分地址、ACL 限制来源，或负载过高无法及时响应。

修复

• 先判断是单个域名、单个解析器还是全局问题，避免一上来就重启 DNS 服务。
• 用 dig +trace 跟随委派链，直接查询各级权威服务器；如果权威本身不响应，修 NS、glue 和权威服务。
• DNSSEC 问题检查 DS/DNSKEY 和签名有效期，修复签名或补齐链；+cd 只用于诊断，不能作为长期关闭校验的方案。
• 委派错误在父区或注册商侧修正 NS 和 glue，修改后等待 TTL 过期并重新验证。
• 传输问题放行 UDP/TCP 53，确认 EDNS 和分片策略；必要时让解析器优先使用 TCP 或调整缓冲区。
• 解析器资源不足时扩容、调高限制、清理异常查询来源；重启只能暂时恢复，必须找到耗尽原因。
• CoreDNS 检查 Corefile 的 forward 上游、超时和并发配置，确认上游可达；loop 插件报错退出时先消除转发环。
• 集群内部域名失败时检查 CoreDNS 到 API server 的网络、ServiceAccount 权限和 Endpoints；外部域名失败时检查出站策略和上游 DNS。
• 补充 SERVFAIL 比例、CoreDNS 错误日志和上游延迟监控，避免只监控解析延迟而漏掉失败率。
• 修复后在多个解析器和不同网络位置复验，清理必要的缓存并观察一个 TTL 周期，确认不会因旧记录再次失败。
• 关键域名配置多个权威服务器和可用性监控；变更 NS、DS 或签名前评估 TTL 和传播时间，避免修复窗口内再次中断。
• 对递归解析器检查 recursion、ACL 和监听地址；对权威服务器检查监听网卡、访问控制和负载，避免只从本机回环地址能查询成功。

相关命令

• dig — 查询状态、委派链和 DNSSEC
• nslookup — 快速验证解析结果
• resolvectl — 本机解析器状态与缓存
• getent — 按 NSS 顺序验证解析
• tcpdump — 抓取 53 端口流量
• named-checkzone — 检查 Zone 配置
• kubectl — CoreDNS 与网络策略
• coredns — CoreDNS 配置与插件
• dns-troubleshooting — 集群 DNS 排查

参考链接

• RFC 1034: 域名系统概念
• RFC 2308: DNS 负缓存
• RFC 4033: DNSSEC 介绍
• CoreDNS 文档
• Kubernetes DNS

读完自测

合上页面，先回答，再展开对照。

1. SERVFAIL 和 NXDOMAIN 的含义有什么不同？
2. dig +dnssec 返回 SERVFAIL，但 dig +cd 能解析成功，说明什么？
3. Kubernetes 内只有集群域名解析失败、外部域名正常，应重点检查什么？