dns劫持本质是中间设备篡改dns响应，排查重点在于验证返回ip是否可信：先用nslookup对比本地与公共dns结果，再通过dig+trace定位劫持节点，最后以--dns硬指定可信dns或绑定只读resolv.conf绕过污染源。
dns 劫持导致的业务异常，本质是容器发出的 dns 查询被中间设备（如路由器、内网 dns 代理、防火墙、甚至恶意软件）篡改响应，返回错误 ip 或超时，而非配置缺失或服务不可达。排查重点不是“有没有 dns”，而是“返回的是否可信”。
确认是否为劫持而非单纯失败
先排除常规故障，再聚焦劫持特征：
- 在容器内执行 nslookup example.com 和 nslookup example.com 8.8.8.8 —— 若前者失败/返回异常 IP，后者成功且 IP 合理，说明本地 DNS 服务器（如 127.0.0.11 或宿主机配置）可能被劫持
- 用 dig +trace example.com 观察完整解析链：若在某一级（如企业 DNS 或 ISP DNS）开始返回非权威答案（ANSWER SECTION 中出现非官方 IP 或 CNAME 指向可疑域名），即存在中间劫持
- 对比宿主机与容器结果：若宿主机解析正常，而容器内解析结果异常（尤其返回 127.0.0.1、192.168.x.x、或已知广告/拦截页 IP），大概率是容器所用 DNS 被污染或重定向
定位劫持发生位置
DNS 请求路径为：容器 → Docker 内置 resolver（127.0.0.11）→ 上游 DNS（来自 daemon.json / --dns / 宿主机）→ 实际递归服务器。劫持可能发生在任一跳：
- 检查容器内 /etc/resolv.conf：若 nameserver 是 127.0.0.11，需进一步验证其上游；若直接是 192.168.1.1 或内网地址，该地址本身可能已被劫持
-
查 Docker daemon 的上游配置：运行 cat /etc/docker/daemon.json，看
"dns"字段是否指向了企业 DNS；若未配置，Docker 默认会读取宿主机/etc/resolv.conf，而该文件若含nameserver 127.0.0.53（systemd-resolved），需确认 resolved 是否被策略重写 - 测试上游 DNS 是否可信：在容器中直接向疑似上游发起查询，例如 nslookup example.com 192.168.10.1（替换为你环境中的 DNS 地址）。若它返回错误结果，说明劫持点就在那里
绕过或阻断劫持路径
不依赖可疑中间节点，建立可信解析通道：
-
启动容器时硬指定公共可信 DNS：使用
--dns 1.1.1.1 --dns 8.8.8.8，跳过内置转发器和所有中间 DNS，让容器直连权威递归服务器 -
禁用 Docker 自动过滤，复用宿主机干净配置：若宿主机 DNS 正常，可在
/etc/docker/daemon.json中添加"dns": ["1.1.1.1"], "dns-opt": ["ndots:0"]并重启 dockerd，避免继承被污染的宿主 resolv.conf -
对关键业务容器，绑定只读的可信 resolv.conf：用
--mount type=bind,source=/dev/null,target=/etc/resolv.conf,readonly清空默认配置，再配合--dns显式注入，防止任何自动覆盖 -
在应用层加固（适用于长期运行服务）：如 Java 应用可设置
-Dsun.net.inetaddr.ttl=0禁用 DNS 缓存；Node.js 可用dns.setServers(['1.1.1.1'])强制上游
验证劫持是否解除
修复后不能只看“能解析”，要确认结果真实可信：
- 执行 dig example.com @1.1.1.1 +short 和 dig example.com @8.8.8.8 +short，比对结果是否一致且符合预期
- 用 curl -v https://example.com 查看实际连接 IP，确认与 dig 结果匹配，而非跳转到广告页或拦截页
- 对业务关键域名（如 API 域名、数据库域名），抓包验证：在容器内 tcpdump -i any port 53 -w dns.pcap，导出后用 Wireshark 检查响应报文中的 ANSWER 是否权威、无重定向
