ndots值过高导致go应用dns解析超时，因k8s默认ndots:5触发多次搜索域拼接查询；推荐通过godebug=netdns=go、构建加-tags netgo或手动补全fqdn（如redis.default.svc.cluster.local.）规避，而非直接调低ndots。
ndots值过高导致Go应用DNS解析超时
Go标准库的net.Resolver在K8s里默认走glibc或musl的getaddrinfo，但实际行为取决于构建方式和运行时环境；更关键的是，K8s Pod的/etc/resolv.conf里默认写入ndots:5，而Go的DNS resolver会严格遵守它——只要域名点号数＜5，就先尝试拼接搜索域，逐个发起A/AAAA查询。比如查redis，会依次试redis.default.svc.cluster.local.、redis.svc.cluster.local.、redis.cluster.local.……直到5次失败才退回到redis.。一次解析可能触发10+次UDP请求，加上超时重试，很容易卡住http.DefaultClient这类阻塞调用。
实操建议：
- 检查Pod内
/etc/resolv.conf：确认ndots值是否真为5（K8s默认），以及search行是否含过多层级（如default.svc.cluster.local svc.cluster.local cluster.local） - 临时验证：进Pod执行
strace -e trace=sendto,recvfrom go run main.go 2>&1 | grep -E "(sendto|recvfrom).+udp"，看实际发了几个DNS包 - 不要直接改
ndots为1——虽然能减查询次数，但会破坏K8s内部服务发现（如mysql无法自动补全为mysql.default.svc.cluster.local）
Go应用绕过ndots的三种可行路径
Go本身不提供运行时动态开关ndots的API，但有三个落地性较强的规避方式，按推荐顺序排列：
- 构建时加
-tags netgo并确保GODEBUG=netdns=go生效：强制用Go纯实现DNS解析器，它会忽略ndots和search，只做一次完整域名查询（前提是传入的域名带结尾点号，如"redis.default.svc.cluster.local."）。注意：musl镜像（如alpine）必须加此tag，否则fallback到系统resolver - 启动时设环境变量
GODEBUG=netdns=cgo（默认）→ 改为netdns=go，效果同上，但需确保二进制是用netgotag编译的，否则无效 - 代码层手动补全FQDN：对已知的K8s服务名，显式拼成
"redis.default.svc.cluster.local."（结尾点号不能少），再传给net.Dial或http.Get；这样无论用cgo还是go resolver，都跳过search域逻辑
K8s层面降低ndots副作用的配置边界
Pod级调整ndots不是万能解法，容易引发隐性故障：
立即学习“go语言免费学习笔记（深入）”；
-
dnsConfig.ndots: 1确实减少查询轮次，但会导致curl mysql失败（没补全到mysql.default.svc.cluster.local），除非所有代码都用FQDN——这在微服务调用链里几乎不可控 -
dnsPolicy: Default+ 自建DNS服务器可彻底绕开K8s默认resolv.conf，但运维成本高，且需确保DNS服务器支持EDNS0以承载大响应（K8s DNS返回的SRV记录可能超512字节） - 真正安全的折中是
dnsConfig.ndots: 2，保留两级搜索（svc.cluster.local和cluster.local），覆盖绝大多数K8s服务名，同时把单次解析的DNS请求数从平均6–8次压到2–3次
调试时别被glibc缓存和Go resolver日志误导
Go的net包不会打印DNS查询详情，而strace看到的UDP流量又混着其他系统调用；更麻烦的是，某些基础镜像（如centos:7）自带nscd，会缓存失败结果长达数分钟，导致你改了ndots却看不到效果。
实操建议：
- 查DNS是否真被缓存：
sudo nscd -g | grep hosts，若hosts cache enabled为yes，临时停掉：sudo nscd -K - 让Go输出resolver行为：启动时加
GODEBUG=netdns=go+2（注意是+不是=），它会在stderr打出每次查询的域名和结果，但仅对netgo生效 - 用
dig +short redis.default.svc.cluster.local @10.96.0.10直连CoreDNS验证底层DNS是否正常，排除网络策略或CoreDNS自身问题
最常被忽略的一点：Go应用如果用了第三方HTTP客户端（如github.com/valyala/fasthttp），它的DNS解析逻辑完全独立于net/http，需要单独确认其resolver是否受ndots影响——通常不受，但它可能自己实现了缓存或超时策略，得另查文档。
