1. 当容器开始"迷路"：DNS问题的表象与本质

想象一下你在陌生城市用导航APP时突然无法查询路线，Docker容器遇到DNS故障时的处境与此类似。近期我遇到这样一个案例：某微服务架构中，使用Docker部署的订单服务无法访问库存服务的域名，控制台持续报错"Name or service not known"。

这类问题通常表现为两种形式：

  • 容器无法解析外部域名（如api.weixin.qq.com）
  • 容器间无法通过服务名称通信（如order-service访问inventory-service）

本质上都是DNS解析链条中的某个环节断裂。Docker默认使用宿主机的DNS配置，但容器化环境存在三个特殊层：

  1. 容器自身的resolv.conf文件
  2. Docker守护进程的DNS代理
  3. 宿主机的网络命名空间

2. 解剖容器DNS的"导航系统"

通过一个实际示例观察默认行为（以下示例均在Linux/Docker 20.10环境下验证）：

# 启动一个临时测试容器
docker run -it --rm alpine sh

# 在容器内查看DNS配置
cat /etc/resolv.conf

# 典型输出内容：
# nameserver 172.17.0.1
# search localdomain

这里的172.17.0.1是Docker默认网桥的网关地址。Docker守护进程在此地址监听DNS请求，并转发给宿主机配置的DNS服务器。这种设计虽然方便，但在以下场景容易出问题：

  • 宿主机DNS配置错误
  • 企业内网强制使用特定DNS服务器
  • 容器使用自定义网络驱动
  • 云环境中的网络安全组限制

3. 手动修复DNS的三种武器

3.1 临时解决方案：运行时指定DNS

# 强制使用Google公共DNS
docker run --dns 8.8.8.8 --dns 8.8.4.4 nginx

# 查看容器配置验证
docker inspect --format='{{.HostConfig.Dns}}' 容器ID
# 预期输出：[8.8.8.8 8.8.4.4]

该方法适用于快速测试，但需要为每个容器单独配置，不适合生产环境。

3.2 全局配置方案：修改Docker守护进程

# 创建/修改配置文件
sudo tee /etc/docker/daemon.json <<EOF
{
  "dns": ["208.67.222.222", "208.67.220.220"],
  "dns-opts": ["use-vc"]  # 强制使用TCP查询
}
EOF

# 重启Docker服务
sudo systemctl restart docker

这种方法会影响所有新建容器，但需要注意：

  • 修改后需要重建容器才能生效
  • 可能与企业安全策略冲突
  • 在Swarm集群中需要同步到所有节点

3.3 高级网络配置：自定义Docker网络

# 创建带自定义DNS的网络
docker network create \
  --driver=bridge \
  --subnet=192.168.5.0/24 \
  --gateway=192.168.5.1 \
  --opt "com.docker.network.bridge.name"="mybridge" \
  --dns=10.200.0.2 \
  my-custom-net

# 容器加入该网络
docker run --network=my-custom-net nginx

这种方案适合需要精细控制网络的环境，例如：

  • 多租户隔离场景
  • 混合云部署
  • 需要对接企业内部DNS服务器

4. 典型故障的排查路线图

当遇到解析失败时，建议按以下步骤排查：

# 步骤1：验证基础网络连通性
docker exec 容器ID ping 8.8.8.8

# 步骤2：检查容器DNS配置
docker exec 容器ID cat /etc/resolv.conf

# 步骤3：测试DNS解析
docker exec 容器ID nslookup google.com

# 步骤4：追踪DNS查询路径
docker exec 容器ID apk add --no-cache bind-tools  # Alpine安装dig
dig +trace google.com

常见错误模式及对策：

  • SERVFAIL响应：检查上游DNS服务器状态
  • 超时无响应：验证网络安全组规则
  • NXDOMAIN错误：确认域名拼写和服务发现机制

5. 技术方案的权衡抉择

5.1 方案对比表

方案类型 适用场景 优点 缺点
运行时指定DNS 快速测试/临时环境 即时生效，灵活度高 无法统一管理
守护进程配置 标准化生产环境 全局生效，便于管理 需要重启Docker服务
自定义网络 复杂网络架构 细粒度控制 增加运维复杂度

5.2 避坑指南

  • DNS缓存问题：修改配置后需重建容器，因为旧容器可能缓存错误配置
  • MTU值不匹配：在某些VPN环境中可能出现报文分片问题
  • IPv6兼容性：混合协议栈可能导致解析优先级异常
  • SELinux限制：在RHEL系系统中可能拦截DNS请求

6. 从故障中学到的经验

通过这次排障之旅，我们总结出容器网络治理的三大原则：

  1. 环境隔离：开发、测试、生产环境应使用不同的DNS策略
  2. 配置即代码：将网络配置纳入版本控制系统管理
  3. 渐进式验证：从ping到nslookup逐步缩小问题范围

未来面对容器网络问题时，建议建立"三层诊断"思维：

  • 第一层：容器内部配置（resolv.conf）
  • 第二层：Docker网络驱动（bridge/host/macvlan）
  • 第三层：宿主机及底层基础设施

记住，好的DNS配置应该像空气一样——用户感受不到它的存在，但整个系统都依赖它顺畅运作。当你下次看到"Name or service not known"时，希望这篇文章能成为你的数字导航仪。