症状是：主机具有适当的网络访问权限，但是在容器中运行的程序无法解析DNS名称（在进行更多调查之前，它似乎是“无法访问网络”）。

$ sudo docker run -ti mmoy/ubuntu-netutils /bin/bash
root@082bd4ead733:/# ping www.example.com
... nothing happens (timeout) ... ^C
root@082bd4ead733:/# host www.example.com
... nothing happens (timeout) ... ^C

（docker映像mmoy / ubuntu-
netutils是基于Ubuntu
ping并host附带的简单映像，在此很方便，因为网络断开了，我们无法使用apt install这些工具）

问题来自于以下事实：Docker自动将Google的公共DNS配置为容器内的DNS服务器：

root@082bd4ead733:/# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 8.8.8.8
nameserver 8.8.4.4

这仅适用于许多配置，但是当主机运行在某些防火墙规则过滤了Google的公共DNS的网络上时，显然不起作用。

发生这种情况的原因是：

• Docker首先尝试在主机上和容器内配置相同的DNS服务器。
• 主机运行dnsmasq（DNS缓存服务）。dnsmasq充当DNS请求的代理，因此主机中明显的DNS服务器/etc/resolve.conf是nameserver 127.0.1.1，即localhost。
• 主机的dnsmasq仅侦听来自localhost的请求，并阻止来自Docker容器的请求。
• 由于127.0.1.1在docker中无法使用，因此docker会退回到Google的公共DNS，而后者也不起作用。

DNS在Docker容器中损坏的原因可能有多种。这个问题（和答案）涵盖以下情况：

• 使用dnsmasq。要检查是否是这种情况：
  • ps -e | grep dnsmasq在主机上运行。如果输出为空，则说明您没有在运行dnsmasq。
  • 检查主机的resolv.conf，它可能包含类似的条目nameserver 127.0.1.1。如果包含nameserver 127.0.0.53，您可能正在运行systemd-resolved而不是dnsmasq。如果是这样，您将无法使用该解决方案将DNS请求散布到dnsmasq（使用的那个listen-address=172.17.0.1）。systemd-resolved硬编码一个事实，即它仅在“ lo”接口上侦听，因此没有简单的方法来适应此解决方案。以下其他答案将与systemd-resolved一起使用。
• Google的公共DNS已被过滤。运行host www.example.com 8.8.8.8。如果失败或超时，则说明您处于这种情况。

在此配置中获得正确的DNS配置的解决方案是什么？