CoreDNS解析偶发5秒超时，根源常是glibc串行fallback机制：首个nameserver超时（默认timeout:5 attempts:2）导致阻塞，而非CoreDNS自身故障；需先验证/etc/resolv.conf是否指向CoreDNS、再排除上游转发延迟或health_check等配置干扰。
CoreDNS 解析偶发性超时 5 秒，基本就是 glibc 的默认 DNS 查询超时机制在起作用：第一个 nameserver 响应慢或丢包，它会卡满 timeout:5 attempts:2（即最多等 10 秒），而你观察到的“5 秒”往往是第一次尝试失败后、第二次重试前的等待间隙，或恰好落在某次超时边界上。
确认是不是 CoreDNS 本身的问题，而不是客户端配置
别一上来就查 CoreDNS 日志。先验证调用方是否真的在走 CoreDNS：
- 检查 Pod 的
/etc/resolv.conf：必须是nameserver 10.96.0.10（或你集群的 kube-dns Service IP），且search域合理；如果里面写了8.8.8.8或127.0.0.53，那根本没经过 CoreDNS - 检查 Node 上的
/etc/resolv.conf：如果宿主机配了多个nameserver，且第一个不可达，dig @10.96.0.10却能通，说明问题不在 CoreDNS，而在客户端 resolver 的串行 fallback 逻辑 - 运行
nslookup service-b.internal 10.96.0.10（直连 CoreDNS）：反复执行 100 次，看是否也出现偶发超时；如果稳定
抓包定位到底是哪一跳卡住的
在出问题的 Pod 所在 Node 上抓包，目标是 CoreDNS 的 ClusterIP 和真实 Pod IP：
- 先确认 CoreDNS Pod 地址：
kubectl -n kube-system get pod -o wide | grep coredns - 在 Node 上执行：
tcpdump -i any host 10.96.0.10 and port 53 -w coredns-53.pcap（捕获发往 Service 的请求） - 同时再抓一条：
tcpdump -i any host 10.32.0.6 and port 53 -w coredns-pod.pcap（替换为真实 Pod IP） - 复现一次超时后分析：如果第一条有请求但第二条没对应包 → 卡在 kube-proxy DNAT 或 conntrack；如果第二条有请求但无响应 → CoreDNS 处理慢或 upstream 超时；如果两条都有响应但耗时 >5s → 看响应内容：是否是
SERVFAIL或空答案（说明转发链断裂）
检查 CoreDNS 配置里有没有隐藏的 timeout 或 forward 延迟
默认 CoreDNS 配置中 forward 插件不设超时，会继承系统默认值，但某些定制配置可能加了 health_check 或 policy 引入隐式延迟：
- 检查
corednsConfigMap：kubectl -n kube-system get cm coredns -o yaml - 重点看
forward行：如果有类似forward . 10.1.1.10 { policy sequential }，且10.1.1.10响应慢，就会拖累整条链；更危险的是写了health_check 5s，它会在每次查询前探测上游健康状态，探测失败就 fallback，探测本身就要耗时 - 检查是否启用了
cache插件但 TTL 过短（如cache 10），导致高频穿透到上游；或者没启用cache，所有请求都打到 upstream - 临时禁用 health_check 测试：
kubectl edit cm -n kube-system coredns，删掉health_check行，重启 CoreDNS Pod，观察是否还偶发 5s
绕过 kube-proxy 直连 CoreDNS Pod 排除 iptables/conntrack 干扰
Service 的 ClusterIP 是一层抽象，背后依赖 iptables DNAT 和 conntrack，这两者在高并发或 conntrack 表满时会显著增加延迟：
- 获取一个 CoreDNS Pod 的真实 IP：
kubectl -n kube-system get pod coredns-abcde -o wide - 在业务 Pod 内直接 dig：
dig @10.32.0.6 example.local +short（用真实 IP，不是 10.96.0.10） - 如果直连稳定 dmesg | grep "nf_conntrack: table full"，或调大
net.netfilter.nf_conntrack_max - 若直连也偶发超时，则聚焦 CoreDNS 自身资源（CPU limit 是否被压满）、upstream DNS 健康度、或是否开启了 debug 日志导致 I/O 阻塞
真正容易被忽略的是：CoreDNS 默认不记录单次查询耗时，log 插件只打成功/失败，不打 latency；想确认是不是某次 upstream 转发卡住，必须开 debug 模式并配合 prometheus 抓 coredns_dns_request_duration_seconds_bucket 直方图——5 秒超时一定会落在 le="5" 桶之外。
