在本地开发和测试场景中，经常需要把特定域名解析到指定的 IP 地址，比如将 api.local 指向运行在本机或容器内的服务。手动修改 /etc/hosts 虽然可行，但当域名数量增多、多个项目并行开发时，维护成本就会明显上升。利用 Docker 部署一个本地 DNS 服务，可以集中管理解析规则，还能与容器网络集成，是更优雅的解决方案。
本文会分别介绍使用 dnsmasq 和 CoreDNS 两种轻量级工具来搭建本地 DNS 服务的完整流程。dnsmasq 配置简单、自带 DHCP 和缓存功能，适合快速上手；CoreDNS 插件化架构更灵活，适合需要更复杂解析逻辑的场景。两种方案都可以通过 Docker 一键启动，并支持通过配置文件或命令行参数自定义解析记录。
为什么选择 Docker 部署本地 DNS
传统的本地 DNS 方案通常需要直接安装并配置 dnsmasq、BIND 等软件，容易与系统自带的 DNS 组件产生冲突，例如 Ubuntu 上的 systemd-resolved 会占用 53 端口。把 DNS 服务跑在容器里，除了隔离环境、便于清理之外，还能通过 Docker 的网络特性控制解析范围，例如只让容器网络使用该 DNS，而宿主机保持默认设置。
另外，Docker 容器本身也依赖 DNS 进行服务发现和外部通信。如果你搭建了一个微服务测试环境，多个容器之间需要通过域名互相访问，一个共享的本地 DNS 容器就能统一处理这些解析请求，避免在每个容器里反复修改 hosts 文件。Docker 的 bridge 网络允许自定义 DNS 地址，这为集成提供了便利。
类型繁多的 DNS 镜像也降低了使用门槛：jpillora/dnsmasq 提供了内置的 Web 管理界面，适合可视化配置；官方 coredns 镜像支持通过 ConfigMap 风格的配置文件挂载；还有专门针对开发环境的 dnsdock、vagrant-dns 等工具。不过对大多数场景来说，dnsmasq 和 CoreDNS 已经足够。
使用 dnsmasq 搭建本地 DNS 服务
dnsmasq 是一个轻量级 DNS 转发器和 DHCP 服务器，常被用在路由器上。它支持通过修改 hosts 文件或使用地址记录来响应查询，对于本地开发非常合适。下面先创建一个配置文件 dnsmasq.conf，内容如下：
# 监听所有网络接口 interface=* # 不读取 /etc/resolv.conf 中的上游 DNS no-resolv # 指定上游 DNS 服务器 server=223.5.5.5 server=8.8.8.8 # 自定义本地解析规则 address=/dev.ipipp.com/192.168.1.100 address=/api.local/127.0.0.1 # 缓存大小 cache-size=1000 # 日志输出到标准输出 log-queries log-facility=-
接着使用 docker run 命令启动容器，将主机的 53 端口映射到容器的 53 端口，同时挂载配置文件：
docker run -d \ --name local-dns \ -p 53:53/udp \ -p 53:53/tcp \ -v $(pwd)/dnsmasq.conf:/etc/dnsmasq.conf \ --restart=unless-stopped \ jpillora/dnsmasq
这里需要同时映射 UDP 和 TCP 端口，因为 DNS 查询通常走 UDP，但某些大数据包或区域传输会使用 TCP。jpillora/dnsmasq 镜像还内置了一个 Web 管理界面，默认运行在 8080 端口，如果你需要图形化操作，可以额外添加 -p 8080:8080 参数，访问 http://127.0.0.1:8080 即可管理解析记录。
如果你的宿主机自身已经占用了 53 端口（例如 systemd-resolved 服务），则需要先停用或修改该服务。Ubuntu 系统可以执行 sudo systemctl stop systemd-resolved 并禁用，或者修改其配置让出 53 端口。也可以把容器的 53 端口映射到非特权端口，比如 -p 5353:53/udp，但这样本机查询时需要指定端口，使用起来不太方便。
验证服务是否正常，可以使用 dig 或 nslookup 命令：
dig @127.0.0.1 dev.ipipp.com # 期望返回 192.168.1.100 nslookup api.local 127.0.0.1 # 期望返回 127.0.0.1
如果想让整个宿主机都使用这个 DNS，可以修改 /etc/resolv.conf 文件，把 nameserver 指向 127.0.0.1。不过在某些系统上该文件会被 NetworkManager 或 systemd-resolved 覆盖，更好的做法是直接在网络设置中调整 DNS 地址，或者借助 resolver 配置。
使用 CoreDNS 搭建更灵活的本地 DNS
CoreDNS 是一个用 Go 编写的插件化 DNS 服务器，在 Kubernetes 集群中广泛使用。它通过 Corefile 配置文件定义插件链，可以实现域名重写、负载均衡、缓存等多种功能。与 dnsmasq 相比，CoreDNS 更适合需要复杂解析逻辑的场景。
准备一个 Corefile，例如：
.:53 {
# 打印查询日志
log
# 错误日志
errors
# 读取本文件中的解析记录
hosts {
192.168.1.100 dev.ipipp.com
127.0.0.1 api.local
fallthrough
}
# 缓存所有查询结果
cache 30
# 将剩余请求转发到上游 DNS
forward . 223.5.5.5 8.8.8.8
}
然后运行容器：
docker run -d \ --name coredns \ -p 53:53/udp \ -p 53:53/tcp \ -v $(pwd)/Corefile:/Corefile \ coredns/coredns
CoreDNS 的 hosts 插件相当于一个内置的 hosts 文件，可以集中配置本地域名。如果解析记录很多，也可以单独维护一个 hosts 文件并使用 hosts /etc/coredns/hosts 加载。此外，template 插件甚至可以动态生成响应，但这里不展开。
CoreDNS 的日志默认输出到标准输出，可以通过 docker logs coredns 查看查询记录。与 dnsmasq 类似，如果宿主机 53 端口被占用，也需要先解决冲突。
将本地 DNS 集成到 Docker 网络中
如果你希望容器之间通过自定义域名互相访问，不需要在宿主机层面配置 DNS，而是让 Docker 网络使用你搭建的 DNS 容器作为解析服务器。Docker 创建自定义网络时支持 --dns 参数指定 DNS 服务器地址。
首先创建一个网络并指定 DNS：
docker network create --driver bridge \ --dns 172.18.0.10 \ local-dev-net
这里的 172.18.0.10 需要替换为你的 DNS 容器在该网络中的 IP。为了让 DNS 容器拥有固定 IP，可以在创建网络时指定子网，然后在运行 DNS 容器时使用 --ip 参数。也可以使用容器名代替 IP，Docker 的嵌入式 DNS 会解析容器名，但前提是容器都在同一个自定义网络中。
完成网络创建后，将 DNS 容器和其他需要解析的容器都连接到该网络：
docker network connect local-dev-net local-dns # 运行其他容器时加入该网络 docker run -d --name app1 --network local-dev-net myapp
这样 app1 容器在查询 dev.ipipp.com 时，会先向 172.18.0.10 这个 DNS 服务器发起请求，从而获得自定义解析结果。如果你使用 docker-compose，可以在 networks 配置中声明 custom_dns 选项，进一步简化管理。
常见问题与性能调优
端口冲突是最常见的问题之一。很多 Linux 发行版默认运行 systemd-resolved 监听 127.0.0.53:53，导致容器无法绑定宿主机 53 端口。可以通过 sudo ss -ulnp | grep :53 查看占用进程，再决定停止服务或改用其他端口。在 macOS 上也有类似情况，但 Docker Desktop 通常会处理好端口转发。
另一个常见问题是容器重启后解析规则丢失。解决方案是挂载配置文件并开启 --restart=always 或 unless-stopped 策略，确保容器和配置持久化。dnsmasq 和 CoreDNS 都支持从文件读取配置，无需每次启动都手动指定参数。
性能方面，DNS 查询的延迟大部分来自上游转发。可以适当增加缓存时间，dnsmasq 通过 cache-size 控制缓存条数，最小 TTL 和最大 TTL 也可以调节；CoreDNS 的 cache 插件可以设置 success 和 denial 的缓存时长。对于本地开发来说，默认参数往往已经足够，但如果多个项目频繁请求相同域名，缓存能明显降低上游压力。
最后提醒一点：在 Linux 上使用 Docker 启动 DNS 容器时，如果启用了 SELinux，可能会阻止容器读取挂载的配置文件，需要添加 :z 或 :Z 标志（例如 -v $(pwd)/dnsmasq.conf:/etc/dnsmasq.conf:z）。不同发行版表现不同，遇到权限错误时可以检查 SELinux 状态。
通过以上两种方案，你可以根据实际需求选择 dnsmasq 或 CoreDNS，快速在本地搭建一个稳定、灵活的 DNS 服务。随着项目复杂度的提升，还可以进一步扩展解析规则，甚至与 CI/CD 流程结合，实现测试环境的自动域名分配。
Docker DNS本地DNS容器化DNS修改时间：2026-09-27 14:55:14