应避免在dockerfile中硬写/etc/resolv.conf，因其会在容器启动时被docker覆盖；正确做法是让镜像兼容多种dns来源，通过entrypoint运行时自适应、buildkit构建参数动态配置、预留编排平台dns兼容层来实现生产级dns适配。
直接在 Dockerfile 里硬写 /etc/resolv.conf 是常见误区——它会在容器启动时被 Docker 覆盖，尤其当使用 --dns 或 daemon.json 配置时。真正可靠的适配方式，是让镜像“兼容多种 DNS 来源”，而非“强行覆盖”。以下是面向生产复杂网络（如混合云、内网隔离、多租户 DNS 策略）的 Dockerfile 编写要点。
避免 RUN echo "nameserver ..." > /etc/resolv.conf
该写法仅在构建阶段生效，镜像运行后会被 Docker 自动重写。实测中，哪怕你用 chmod 444 /etc/resolv.conf 锁定文件，Docker 启动时仍会挂载只读 tmpfs 并注入新内容。这不是 bug，而是设计机制：Docker 必须控制 DNS 解析行为以保障网络一致性。
所以请放弃“永久写死 DNS”的思路，转而做三件事：
- 确保基础镜像不依赖特定 DNS（比如删掉 Ubuntu 镜像中自带的
systemd-resolved冲突配置） - 在应用启动脚本中加入 DNS 可用性探测和 fallback 逻辑
- 用 ENTRYPOINT 封装轻量初始化，而非靠构建时静态写入
用 ENTRYPOINT 做运行时 DNS 自适应
适合需要区分内网/公网解析、或对接自建 DNS 服务（如 CoreDNS、BIND）的场景。示例结构如下：
Dockerfile 片段FROM ubuntu:22.04 <h1>安装必要工具（nslookup、curl、jq）</h1><p>RUN apt-get update && apt-get install -y \ dnsutils \ curl \ && rm -rf /var/lib/apt/lists/*</p><h1>复制启动脚本</h1><p>COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh</p><p>ENTRYPOINT ["/entrypoint.sh"] CMD ["your-app-start-command"] </p>entrypoint.sh 示例逻辑
#!/bin/sh # 检查 /etc/resolv.conf 是否含内网 DNS（如 192.168.x.x 或 10.x.x.x） if grep -qE '^(nameserver[[:space:]]+192\.168\.|nameserver[[:space:]]+10\.)' /etc/resolv.conf; then echo "[INFO] Detected internal DNS, enabling service discovery mode" export APP_ENV=internal else echo "[INFO] Using default DNS, enabling public fallback" export APP_ENV=public fi <h1>可选：预热 DNS 缓存或探测关键域名</h1><p>nslookup auth.internal.svc 2>/dev/null | grep "Address:" >/dev/null && \ echo "[OK] Internal domain resolvable" || \ echo "[WARN] Internal DNS may be unreachable"</p><p>exec "$@" </p>
配合多环境构建参数动态注入 DNS 策略
当不同客户部署环境 DNS 策略差异大（例如金融客户强制走 10.1.1.10，SaaS 客户允许 8.8.8.8），可用 BUILDKIT 和 --build-arg 实现条件化行为：
# Dockerfile 支持 ARG（需启用 BuildKit） # 构建时传参：docker build --build-arg DNS_MODE=corp -t myapp . <p>ARG DNS_MODE=public</p><h1>根据参数安装不同配置工具或默认依赖</h1><p>RUN case "$DNS_MODE" in \ corp) apt-get update && apt-get install -y bind9-host ;; \ cloud) apt-get update && apt-get install -y dnsutils ;; \ *) apt-get update && apt-get install -y curl ;; \ esac</p><h1>不写 resolv.conf，但提供配置模板供运行时选用</h1><p>COPY templates/ /etc/myapp/templates/ </p>
这样镜像本身不绑定具体 DNS 地址，而是由交付流程决定行为，符合 DevSecOps 的不可变基础设施原则。
为 Kubernetes 或 Swarm 环境预留 DNS 兼容层
若镜像最终跑在编排平台，要主动适配其 DNS 行为：
- Kubernetes Pod 默认使用 kube-dns/CoreDNS（地址为
10.96.0.10），且自动注入search域（如default.svc.cluster.local） - Docker Swarm 自定义网络内置 DNS（
127.0.0.11），支持容器名解析
建议在 Dockerfile 中显式声明兼容性：
# 显式说明支持标准容器 DNS 协议 LABEL org.opencontainers.image.description="DNS-aware image: respects \ /etc/resolv.conf, supports 127.0.0.11 (Swarm) and kube-dns (K8s)"
并在文档中注明：“无需修改 resolv.conf；如需强制指定上游 DNS，请通过 --dns 启动参数或平台 DNS 策略配置。”
