来源：刘军军 | 发布日期：2026-05-28

K8s DNS 故障排查实战：iptables 封禁 53 端口引发的 DNS 雪崩

一句话复盘： 运维安全加固脚本误加了一条 iptables -A OUTPUT -p udp --dport 53 -j DROP，导致 DNS 上游转发失败 → CoreDNS 超时积压崩溃 → 全集群 DNS 解析不可用。从症状到根因，层层递进排查了 76 分钟。

故障背景

• 时间：周四 14:23 监控告警触发
• 症状：3 台节点报 Connection refused 和 dial tcp: lookup service-order on 10.96.0.10:53: no such host
• 环境：Kubernetes 集群 + CentOS 7.9
• DNS 架构：集群内 CoreDNS (10.96.0.10) → 上游内网 bind9 (10.10.0.2) → 公网 DNS (114.114.114.114 / 8.8.8.8)

第一阶段：确认是 DNS 问题（14:31）

登录告警节点，直接测试：

# 测试内部域名解析
nslookup service-order.default.svc.cluster.local
# 输出: ;; connection timed out; no servers could be reached

# 测试公网域名
nslookup www.baidu.com
# 输出: ;; connection timed out; no servers could be reached

# 用 IP 绕过 DNS 测试网络连通性
curl -I http://10.10.1.50:8080/health
# 返回 200 → 网络本身没问题，纯 DNS 故障

关键判断： IP 通、域名不通 → 定位到 DNS 链路。

第二阶段：排查 CoreDNS（14:38）

# CoreDNS Pod 全部 CrashLoopBackOff
kubectl get pods -n kube-system | grep coredns
# coredns-5d78c9869d-4xvqk   0/1   CrashLoopBackOff   8   23m
# coredns-5d78c9869d-9bmnp   0/1   CrashLoopBackOff   8   23m

# 查崩溃日志
kubectl logs coredns-5d78c9869d-4xvqk -n kube-system --previous
# [ERROR] read udp ... i/o timeout          ← 上游 DNS 超时
# [FATAL] listen tcp 0.0.0.0:53: bind: address already in use  ← 端口冲突

# 查 53 端口占用
ss -tunlp | grep :53
# systemd-resolved (pid=612) 占用 127.0.0.1:53

发现双重问题：

1. UDP 53 端口被 systemd-resolved 占用 → CoreDNS（hostNetwork 模式）启动时绑定失败
2. 上游 DNS 响应超时 → CoreDNS 转发请求一直等待，资源耗尽后崩溃

第三阶段：追踪上游 DNS 超时（14:45）

# 直接测上游 bind9 响应
dig @10.10.0.2 www.baidu.com +stats
# Query time: 4823 msec  ← 正常应在 10ms 以内

# 连续测试
for i in {1..5}; do dig @10.10.0.2 www.qq.com | grep "Query time"; done
# 4901ms, 5023ms, 4756ms, timeout, 4832ms  ← 严重变慢，偶发超时

# 登录 DNS 服务器检查
ssh [email protected]
# bind 服务在跑，但日志显示向上游转发全部超时
tail -100 /var/log/named/named.log
# fetch: www.baidu.com/A: SERVFAIL
# DNS server: 114.114.114.114#53: no response
# DNS server: 8.8.8.8#53: no response

# 测试 DNS 服务器自身出站
dig @114.114.114.114 www.baidu.com  # 超时
nc -vzu 114.114.114.114 53         # Connection timed out

# 查防火墙
iptables -L OUTPUT -n -v | grep 53
# DROP  udp  --  0.0.0.0/0  0.0.0.0/0  udp dpt:53  ← 根因！

根因锁定： 运维同事在做安全加固时，在 DNS 服务器上执行了 iptables -A OUTPUT -p udp --dport 53 -j DROP，封禁了所有 UDP 53 出向流量，导致 bind9 无法向上游转发解析请求。

第四阶段：修复（15:04-15:17）

三步修复：

① DNS 服务器上删除 iptables 规则

iptables -D OUTPUT -p udp --dport 53 -j DROP
# 验证
dig @114.114.114.114 www.baidu.com | grep "Query time"
# Query time: 23 msec  ← 恢复

② K8s 节点上解决 CoreDNS 端口冲突

# 修改 /etc/systemd/resolved.conf
[Resolve]
DNS=10.10.0.2
DNSStubListener=no    # 关闭 53 端口监听

systemctl restart systemd-resolved
ss -tunlp | grep :53  # 确认端口已释放

③ 重启 CoreDNS

kubectl rollout restart deployment coredns -n kube-system
# 等待两个 Pod 变为 Running

验证结果： 内部域名、公网域名全部解析正常，3 台节点 2 分钟内监控告警消失。

第五阶段：复盘与加固

故障时间线

故障持续 76 分钟。

加固措施

1. iptables 变更审计 — 用 auditd 监控 iptables 执行 bash auditctl -w /sbin/iptables -p x -k iptables_change

2. DNS 响应时间监控 — Prometheus blackbox_exporter 探测 DNS 延迟，超 200ms 告警

3. CoreDNS 健康检查告警 — 监控 CoreDNS Pod 状态 + API 健康端点

4. 安全加固脚本走 Review 流程 — 不允许在生产 DNS 节点直接执行加固脚本

DNS 故障排查思路总结

域名解析失败 / 解析慢
  │
  ├─ 用 IP 直接访问 → 正常 → 确认是纯 DNS 问题
  │   ├─ cat /etc/resolv.conf → 确认 DNS 服务器地址
  │   ├─ nslookup/dig 直接测试 DNS 服务器
  │   │   ├─ 超时 → DNS 服务器本身有问题
  │   │   └─ 正常 → 客户端到 DNS 的网络/配置问题
  │   ├─ 检查 DNS 服务进程（CoreDNS / bind / dnsmasq）
  │   │   ├─ CrashLoop → 查日志找崩溃原因
  │   │   └─ 端口冲突 → ss -tunlp | grep :53
  │   ├─ 测试上游 DNS 转发
  │   │   ├─ dig @上游IP → 慢/超时 → 上游有问题
  │   │   └─ nc -vzu 上游IP 53 → 超时 → 防火墙封了出向 53
  │   └─ 检查防火墙
  │       ├─ iptables -L -n -v
  │       └─ 找到 DROP udp dpt:53 → 根因！

核心经验

DNS 故障往往是多层叠加——客户端配置、本地 DNS 服务、上游转发、防火墙，任何一层出问题都会导致解析失败。排查要沿着解析链路逐层用 dig 直接测试，快速缩小范围，不要在一层上耗太多时间。

关联页面