直接回答：Pod 的 /etc/resolv.conf 默认带 ndots:5：名字里点少于 5 个就先按 search 域（svc.namespace.svc.cluster.local 等四级组合）逐个尝试，失败后才按绝对域名解析。后果是查一个外部域名 example.com 会先发 4~5 次无效查询（example.com.default.svc.cluster.local 等），DNS 查询量放大数倍，高并发下 CoreDNS CPU 打满、解析延迟上升、超时引发诡异的“偶发网络慢”。
展开解析：优化手段分层：应用侧最简单——访问外部域名时在名字末尾加点（example.com.）跳过 search 域展开，零成本收益大；或 Pod spec 里自定义 dnsConfig 把 ndots 调小（如 2），但要评估集群内短域名访问的兼容性。集群侧：部署 NodeLocal DNSCache（每节点一个 DaemonSet 缓存，Pod 走节点本地链路查询，绕过 conntrack 与 CoreDNS 集群内跳转），这是大集群的标配，同时消除 SNAT 端口冲突导致的 UDP 丢包类诡异故障；CoreDNS 开 cache 插件、按 QPS 用 HPA/cluster-proportional-autoscaler 扩副本；对固定外部依赖在 CoreDNS 配 hosts/rewrite 插件直接应答。排查工具：Pod 内 dig 加 +search 对照、CoreDNS 的 prometheus 指标看每类查询的延迟与 NXDOMAIN 比例（NDOTS 放大的特征就是大量 cluster.local 后缀的 NXDOMAIN）。
追问方向：NodeLocal DNSCache 如何做到节点本地命中？UDP 与 TCP DNS 在该场景各有什么坑？
（约 480 字）