Docker构建命令域名解析失败求助：Debian10环境DNS容器相关问题

看起来你这套Pi-hole -> Bind9 -> DNSCrypt-Proxy的LAN DNS架构确实容易在容器网络交互上出问题，结合你已经做的排查，给你几个针对性的方向：

• 先确认Docker构建过程的实际DNS配置
  运行时容器的resolv.conf没问题，但docker build的环境可能和运行时不一样。试试在构建时强制指定DNS服务器，比如执行：

  docker build --dns 1.1.1.1 --dns 8.8.8.8 --no-cache .
  

  同时检查/etc/docker/daemon.json的语法是否正确（比如逗号、括号有没有遗漏），修改后记得执行systemctl restart docker生效，避免daemon没加载到正确的DNS配置。

• 排查主机DNS链的转发有效性
  主机的resolv.conf首指向自身（Pi-hole），那先验证这条链路能不能正常解析域名：

  1. 在主机上执行dig deb.debian.org，看返回的IP是否正常，有没有超时；
  2. 查看Pi-hole的查询日志，确认Docker daemon发出的DNS请求没有被误拦截（比如把apt源域名当成广告屏蔽了）；
  3. 逐层测试DNS链：用dig @<bind9-container-ip> deb.debian.org验证Bind9是否能转发，再用dig @<dnscrypt-proxy-ip> deb.debian.org验证DNSCrypt的解析能力。

• 检查APT源的解析与连通性
  有可能不是DNS的问题，而是APT源本身无法访问。可以临时修改Dockerfile里的源为Cloudflare镜像源试试：

  RUN echo "deb https://cloudflaremirrors.com/debian buster main" > /etc/apt/sources.list && apt-get update
  

  如果这样能成功，说明原来的源域名在你的DNS链里解析异常，或者源服务器无法访问。

• 排查Docker网络与端口冲突

  1. 检查53端口的占用：执行netstat -tulpn | grep :53，确认是Pi-hole容器在监听，没有其他进程（比如主机自带的bind9）抢占端口；
  2. 试试用自定义bridge网络构建：创建一个独立网络docker network create dns-isolated，然后用docker build --network dns-isolated --no-cache .，避免默认bridge网络的DNS干扰；
  3. 确认你的DNS容器网络模式：如果用了host模式，检查是否和Docker daemon的网络配置冲突，比如Docker daemon会不会尝试使用主机的53端口而被Pi-hole占用。

• 抓包定位流量问题
  如果以上都没线索，用tcpdump抓DNS和HTTP流量：

  # 抓主机上所有53端口的DNS流量
  tcpdump -i any port 53 -w dns-traffic.pcap
  # 同时抓80/443端口的APT流量
  tcpdump -i any port 80 or port 443 -w apt-traffic.pcap
  

  然后执行docker build，结束后分析pcap文件，看DNS请求是否发出、是否收到响应，APT的HTTP请求是否能建立连接。

如果这些思路还没解决问题，把你的DNS容器docker-compose.yml和新容器的Dockerfile贴出来，我可以帮你再针对性分析。

内容的提问来源于stack exchange，提问作者Cybermate