Kubernetes 集群 DNS 间歇性解析失败：ndots 的坑与根治方案

线上一个奇怪的故障：Pod 内 curl 另一个 Service，十次里两三次报 name resolution failure，其余正常。抓包看 DNS 查询全部发出去了，偶尔没有响应。折腾半天，根因是 ndots:5。

一、ndots 是什么

Kubernetes 默认给 Pod 的 /etc/resolv.conf 注入 search 域和 options ndots:5。含义：域名中点数少于 5 个，先按 search 域逐个拼接查询，全部失败后才尝试原始域名。

二、事故还原

业务访问的外部域名是 db.example.com（2 个点）。因为 ndots:5，解析器依次查询 db.example.com.default.svc.cluster.local 等四条 search 后缀，全 NXDOMAIN 后才查真实域名。CoreDNS 上游偶发超时（出口网络抖动），排在第五位的真实查询恰好最容易被掐掉——于是出现概率性解析失败。

三、修复方案

1. 应用侧：外部域名写成绝对形式 db.example.com.（结尾加点），跳过全部 search 拼接。

2. 环境变量：HostAliases 直接注入 /etc/hosts，热路径绕开 DNS。

3. 集群侧：dnsConfig 配置 options ndots:2，代价是集群内短域名必须写全。

4. CoreDNS 侧：开启 forward 同时指向多个上游并配置 max_concurrent，缓解超时连锁。

四、怎么确认是这个问题

Pod 里 cat /etc/resolv.conf 看 ndots 值；dig db.example.com（无点尾）观察是否多出四五条 cluster.local 查询；CoreDNS 日志里 NXDOMAIN 洪水是最直接的证据。

五、沉淀

ndots 是为集群内短域名设计的，副作用是所有外部域名都先在集群内空转一圈。外部依赖重的服务，要么带点访问，要么调低 ndots——概率性 DNS 故障排查时，先把这条列入检查清单。