docker容器dns解析依赖分层机制：应用查询127.0.0.11后，经iptables劫持至docker内置dns转发器，先查容器名映射，未命中则转发至配置的上游dns，全过程基于udp且受网络模式严格约束。
容器 dns 解析不是简单地把宿主机的 /etc/resolv.conf 复制进去，而是一套分层协作机制：底层依赖 linux 网络命名空间隔离、iptables 流量劫持、udp 协议转发，上层由 docker 守护进程统一调度 dns 映射与缓存。关键在于 127.0.0.11 这个地址——它不是真实网卡 ip，而是 docker 在容器网络命名空间中注入的虚拟 dns 端点。
DNS 查询发起：应用层到内核协议栈
当容器内进程调用 getaddrinfo("db") 或执行 ping db 时：
- libc 解析器读取
/etc/resolv.conf，发现唯一 nameserver 是 127.0.0.11 - 构造标准 DNS 查询报文（UDP，目的端口 53），发往 127.0.0.11:53
- 该地址在容器命名空间中并不存在物理接口，但 Linux 内核的 netfilter 模块已通过 iptables 规则提前捕获该流量
- 规则形如：
-A OUTPUT -d 127.0.0.11/32 -p udp --dport 53 -j DNAT --to-destination 127.0.0.11:53（实际由 Docker 自动设置）
嵌入式 DNS 服务：Docker 引擎的本地转发器
127.0.0.11 是 Docker 守护进程在宿主机上维护的一个轻量级 DNS 服务监听点，运行在 Docker daemon 的网络命名空间中（非容器内）：
- 它不直接响应所有查询，而是先查本地映射表：当前自定义网络中所有容器名、别名、服务名 → IPv4/IPv6 地址
- 若命中（例如查询
web，且 web 容器连在同个自定义网络），立即返回 A 记录，TTL 默认为 1 秒（可配置） - 若未命中（例如查询
google.com），则作为上游客户端，将请求转发至配置的外部 DNS（如 daemon.json 中的"dns"数组，或 fallback 到宿主机/etc/resolv.conf） - 整个过程全程基于 UDP，无 TCP 回退逻辑；超时由容器内 libc 的
resolv.conf中options timeout:2 attempts:3控制
网络模式决定 DNS 行为边界
DNS 解析路径高度依赖容器所处的网络驱动类型：
-
bridge（docker0 默认网桥）：容器直接继承宿主机
/etc/resolv.conf，--dns参数有效，但不支持容器名解析（无内置 DNS） -
自定义 bridge 网络：强制使用 127.0.0.11，忽略
--dns和宿主机配置，支持容器名、--network-alias、Docker Compose 中的 service 名解析 -
host 模式：容器共享宿主机网络命名空间，
/etc/resolv.conf完全一致，绕过所有 Docker DNS 逻辑 - overlay（Swarm 或多机场景）：DNS 请求由 Swarm manager 节点上的嵌入式 DNS 统一处理，支持跨节点服务名解析和 VIP 负载分发
真实数据流向图解（以自定义网络为例）
容器 A（IP 172.20.0.3）→ 查询 "redis" → UDP 包发往 127.0.0.11:53 → iptables DNAT 到宿主机 loopback → Docker daemon 接收 → 查内部映射得 redis IP 172.20.0.5 → 封装 DNS 响应 → UDP 返回容器 A → 应用获得目标 IP 并建立连接。
整个链路不经过 docker0 网桥、不触发 NAT、不依赖宿主机 DNS 进程，全部在内核协议栈与 Docker daemon 之间完成，延迟低且可控。
