这里的问题是许多现代 Linux 系统隐式运行 dnsmasq，所以您现在的目标是设置一个 second 实例专门供 Docker 使用。实际上需要 3 个设置才能正确执行此操作：
-
--interface=docker0 监听默认的 Docker 网络接口
-
--except-interface=lo 跳过回环接口的隐式添加
-
--bind-interfaces 关闭 dnsmasq 功能，默认情况下它仍会侦听所有接口，即使它只处理其中一个接口的流量
设置专用 dnsmasq 实例
这些说明显示了在已经定义了默认 dnsmasq 服务的系统上使用 systemd 设置专用 dnsmasq 实例，而不是更改默认系统范围 dnsmasq 实例的设置：
$ sudo cp /usr/lib/systemd/system/dnsmasq.service /etc/systemd/system/dnsmasq-docker.service
$ sudoedit /etc/systemd/system/dnsmasq-docker.service
首先，我们将默认服务设置复制到专用服务文件中。然后我们编辑该服务文件，并查找服务定义部分，应该是这样的：
[Service]
ExecStart=/usr/sbin/dnsmasq -k
我们编辑该部分以定义我们的其他选项：
[Service]
ExecStart=/usr/sbin/dnsmasq -k --interface=docker0 --except-interface=lo --bind-interfaces
entire file 实际上很短：
[Unit]
Description=DNS caching server.
After=network.target
After=docker.service
Wants=docker.service
[Service]
ExecStart=/usr/sbin/dnsmasq -k --interface=docker0 --except-interface=lo --bind-interfaces
[Install]
WantedBy=multi-user.target
[Unit] 部分告诉 systemd 等到网络堆栈和主 docker 守护进程都可用后才能启动此服务，而[Install] 指示在启用服务时要将服务添加到哪个系统状态目标。
然后我们将我们的新服务配置为在系统启动时启动，并显式启动它以供立即使用：
$ sudo systemctl enable dnsmasq-docker
$ sudo systemctl start dnsmasq-docker
作为让服务运行的最后一步，我们检查它是否已按预期启动：
$ sudo systemctl status dnsmasq-docker
我们在该输出中寻找的两个关键行是：
Loaded: loaded (/etc/systemd/system/dnsmasq-docker.service; enabled; vendor preset: disabled)
Active: active (running) since <date & time>
在第一行，注意“启用”状态，而在第二行，“活动（运行）”状态。如果服务没有正确启动，那么额外的诊断信息有望解释原因（尽管不幸的是有时它可能很神秘，因此这篇文章）。
注意：此配置可能无法在系统重新启动时启动dnsmasq-docker，并出现关于未定义docker0 接口的错误。在等待docker.service 似乎可以避免该问题时非常可靠，如果系统重新启动后来自 docker 容器的名称解析不起作用，请尝试运行：
$ sudo systemctl start dnsmasq-docker
配置主机防火墙
为了能够从本地 Docker 容器中使用解析器，我们还需要删除主机和容器中运行的系统之间的网络防火墙：
sudo firewall-cmd --permanent --zone=trusted --change-interface=docker0
sudo firewall-cmd --reload
（这在生产容器主机上绝对是一个糟糕的想法，但在开发人员工作站上可能是一个有用的风险与便利性权衡）
使用 systemd 环境文件配置 Docker
现在我们的本地解析器正在运行，我们需要将 Docker 配置为默认使用它。 Docker 需要docker0 接口的IP 地址而不是接口名称，所以我们使用ifconfig 来检索它：
$ ifconfig docker0 | grep inet
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
因此，对于我的系统，默认docker0 网桥上的主机接口可作为172.17.0.1 访问（将| cut -f 10 -d ' ' 附加到该命令应将输出过滤为仅IP 地址）
由于我假设基于 systemd 的 Linux 带有系统提供的 Docker 包，我们将查询系统包的服务文件以了解服务是如何启动的：
$ cat /usr/lib/systemd/system/docker.service
我们要查找的第一件事是用于启动守护程序的确切命令，它应该如下所示：
ExecStart=/usr/bin/docker daemon \
$OPTIONS \
$DOCKER_STORAGE_OPTIONS \
$DOCKER_NETWORK_OPTIONS \
$INSECURE_REGISTRY
我们要查找的第二部分是服务是否配置为使用环境文件，如以下多行之一所示：
EnvironmentFile=-/etc/sysconfig/docker
当一个环境文件正在使用中（就像在 Fedora 23 上一样），那么更改 Docker 守护程序设置的方法是编辑该文件并更新相关的环境变量：
$ sudoedit /etc/sysconfig/docker
Fedora 23 上现有的 OPTIONS 条目如下所示：
OPTIONS='--selinux-enabled --log-driver=journald'
要更改默认 DNS 解析设置，我们将其修改为如下所示：
OPTIONS='--selinux-enabled --log-driver=journald --dns=172.17.0.1'
然后重启 Docker 守护进程：
$ sudo systemctl restart docker
实施此更改后，Docker 容器现在应该能够可靠地访问您的主机系统可以访问的任何系统（包括通过 VPN 隧道，这是我自己需要弄清楚这一点的原因）
您可以在容器内运行curl 以检查名称解析是否正常工作：
docker run -it centos curl google.com
将google.com 替换为给您带来问题的主机名（因为只有在 Docker 容器内运行进程时遇到名称解析问题，您才应该最终找到此答案）
使用 systemd 插件文件配置 Docker
（警告：由于我的系统使用环境文件，我无法测试下面的基于插入文件的方法，但它应该可以工作 - 我已经包含它，因为 Docker 文档似乎表明他们现在更喜欢使用 systemd 插入文件而不是使用环境文件）
如果系统服务文件没有使用EnvironmentFile，那么整个ExecStart条目可以通过使用插入配置文件来替换：
$ sudo mkdir -p /etc/systemd/system/docker.service.d
$ sudoedit /etc/systemd/system/docker.service.d/daemon.conf
然后我们告诉 Docker 清除现有的 ExecStart 条目并将其替换为具有附加设置的新条目：
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon \
$OPTIONS \
--dns 172.17.0.1 \
$DOCKER_STORAGE_OPTIONS \
$DOCKER_NETWORK_OPTIONS \
$INSECURE_REGISTRY
然后我们告诉 systemd 加载配置更改并重新启动 Docker：
$ sudo systemctl daemon-reload
$ sudo systemctl restart docker
参考资料：