dnspolicy: default 可使 pod 继承 kubelet 启动时读取的宿主机 /etc/resolv.conf，但需确保 --resolv-conf 参数指向正确文件、systemd-resolved 等服务已配置企业 dns 上游，并禁用 nodelocal dnscache 干扰，同时显式声明 dnspolicy: default 避免 hostnetwork 下行为异常。
直接使用 dnsPolicy: Default 就能让 Pod 完全复用宿主机的 /etc/resolv.conf，这是适配复杂企业内网 DNS 的最简路径——但关键不在“设不设”，而在“宿主机配得对不对”。
确保宿主机 DNS 配置真实生效
Pod 继承的是 kubelet 启动时读取的 resolv.conf（不是实时文件），所以不能只改文件就完事：
- 确认 kubelet 启动参数中
--resolv-conf指向的是你预期的配置文件（如/etc/resolv.conf或自定义路径） - 若宿主机使用 systemd-resolved、dnsmasq 或自研代理，需验证该服务实际监听的上游 DNS 是否包含企业内网域名服务器（如 AD 域控、内部 DNS 转发器）
- 在宿主机上执行
systemd-resolve --status或cat /run/systemd/resolve/resolv.conf，比看/etc/resolv.conf更可靠
绕过 CoreDNS 干预，避免解析冲突
ClusterFirst 会强制插入集群 DNS 地址并启用搜索域，而 Default 模式下这些逻辑全部跳过——但要注意隐性干扰：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 禁用 NodeLocal DNSCache：若集群启用了 nodelocaldns，它会劫持 169.254.20.10 流量，导致 Default 策略失效；需确认该 DaemonSet 未部署，或通过 annotation
dns.alpha.kubernetes.io/policy: "Default"显式绕过 - 避免 hostNetwork + ClusterFirst 组合：即使写了 Default，若同时设置
hostNetwork: true又没显式指定 dnsPolicy，K8s 可能因兼容逻辑回退到 Default，但行为不稳定；务必显式声明dnsPolicy: Default
验证与调试要点
别只信 nslookup，要分层确认解析链是否真正走通：
- 进 Pod 执行
cat /etc/resolv.conf，核对 nameserver 是否与宿主机一致（尤其注意是否被 kubelet 自动注入了 127.0.0.53） - 用
dig @<your-dns-ip> internal.service.corp +short</your-dns-ip>直连企业 DNS，排除转发链路问题 - 检查是否受 NetworkPolicy 限制：企业内网常有 UDP 53 出向白名单，确认 Pod 所在 namespace 的 NetworkPolicy 允许访问对应 DNS IP 和端口
补充：当 Default 不够用时的替代方案
如果企业 DNS 要求特定 EDNS 选项、自定义超时或 split-DNS，Default 模式无法满足，此时应切换为 dnsPolicy: None 并配合 dnsConfig：
- 手动写死 nameserver 为企业 DNS 地址（支持最多 3 个）
- 用
options字段添加edns0、timeout:3等参数 - searches 中加入企业内网域名后缀（如
corp、ad.company.local）
