Docker容器内DNS工作机制及非默认端口问题咨询

问题1：我的以下理解是否正确？ #

容器内解析公网域名（如dig www.google.com）的DNS查询数据包，会按以下顺序流经组件：容器本地DNS解析器、主机上的Docker DNS服务器、主机DNS服务器。
具体来说：

• 容器本地DNS解析器仅作为转发器，将所有查询通过容器所在的Docker网络转发至Docker DNS服务器；
• Docker DNS服务器是主机上运行的集中式服务，为同一主机上的所有容器提供服务（除非容器被显式配置为使用其他服务器），可解析容器相关的DNS查询（如容器间通过名称ping通），其他查询则转发至主机DNS服务器。

解答 #

你的理解大体正确，但有两处关键细节需要修正：

• 容器内的127.0.0.11不是传统的本地DNS解析器，而是Docker在容器网络命名空间中注入的内置DNS代理，它只负责转发请求，不做任何本地解析操作。
• Docker DNS服务（由Docker daemon提供）并非服务于同一主机的所有容器，而是仅服务于同一Docker网络内的容器——不同自定义网络的容器默认无法通过名称互相解析，除非配置了跨网络连接。

公网域名解析的完整流程可以细化为：

1. 容器内进程（如dig）发起DNS查询，依据/etc/resolv.conf的配置将请求发往127.0.0.11；
2. 容器内的DNS代理把请求转发到主机上的Docker DNS服务；
3. Docker DNS服务先处理容器名称、Docker服务名称等内部DNS请求；如果是公网域名，则将请求转发到主机系统的DNS服务器（读取主机/etc/resolv.conf的配置）；
4. 响应结果按原路返回给容器内的发起进程。

问题2：为何本地DNS解析器监听非默认端口？ #

在容器（镜像ubuntu:22.10，主机系统ubuntu-22.10）中查看端口使用情况，结果如下：

$ cat /etc/resolv.conf 
nameserver 127.0.0.11

$ netstat -tulpn 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.11:35801        0.0.0.0:*               LISTEN      -                   
udp        0      0 127.0.0.11:58113        0.0.0.0:*                           - 

可见DNS解析器未监听默认端口53，而是监听大于1024的随机端口。但抓包发现DNS响应从端口53发出：

$ tcpdump -i lo port 53 or port 58113 and udp &
$ dig +short www.google.com
03:08:55.215419 IP localhost.47258 > localhost.58113: UDP, length 55
03:08:55.216852 IP localhost.53 > localhost.47258: 41084 1/0/1 A 142.251.46.228 (59)
03:08:55.307792 IP localhost.50668 > localhost.58113: UDP, length 52
03:08:55.308478 IP localhost.53 > localhost.50668: 17391*$ 1/0/1 PTR localhost. (75)

DNS查询从dig选取的端口47258发往58113，但响应从端口53返回。虽知晓该机制合法，但想了解Docker为何设计此不对称流程，而非让本地DNS解析器直接监听端口53。

解答 #

这个不对称端口设计主要出于两个实际考量：

1. 规避特权限制：端口53属于特权端口（端口号<1024），进程要绑定这类端口需要CAP_NET_BIND_SERVICE权限或root身份。Docker的内置DNS代理运行在容器的网络命名空间内，为了遵循最小权限原则，避免给代理赋予额外特权，选择让它绑定随机的高端口（>1024）。
2. 避免端口冲突：如果Docker强制占用容器内的53端口，那么容器内用户自己部署的DNS服务就无法绑定该端口了。使用高端口可以让用户的应用在需要时正常使用53端口（只要具备相应权限）。

至于抓包中看到的响应从端口53返回，是因为容器内的DNS代理在转发请求后，会将主机上Docker DNS服务（监听53端口）的响应源端口修改为53再返回给容器进程——这样容器内的DNS客户端（如dig）会收到符合DNS协议预期的标准端口响应，无需做任何特殊适配。

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