最简洁可复用的做法是在服务级别配置dns字段，支持IP或域名形式的DNS地址，多个地址按序生效，优先级高于宿主机DNS但低于--dns命令行参数。
直接在 docker-compose.yml 的服务级别配置 dns 字段，是最简洁、可复用且符合微服务治理习惯的做法。它让所有相关容器使用一致的 DNS 解析路径，避免因宿主机 DNS 不稳定或内网域名不可达导致的服务调用失败。
服务级 dns 配置（推荐主用）
在每个需统一解析策略的服务中显式声明 dns，确保其 /etc/resolv.conf 被准确覆盖：
- 支持 IP 或域名形式的 DNS 地址，如
192.168.10.5或coredns.internal - 多个地址按顺序生效，建议将内网 DNS 放首位（例如公司 CoreDNS），公网 DNS 作兜底
- 该配置优先级高于宿主机 DNS，但低于
--dns命令行参数（若手动运行则会覆盖）
网络级 dns 继承（适合批量管理）
若多个服务共用同一套 DNS 策略，可在自定义网络定义中统一设置，服务接入该网络时自动继承：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 需配合
driver: bridge或overlay使用，host网络不生效 - 写法示例：
networks: mynet: driver: bridge dns: [192.168.10.5, 1.1.1.1] - 接入该网络的服务无需重复写
dns，减少配置冗余，便于后期集中调整
配合 dns_search 提升内网解析体验
微服务常依赖短域名（如 auth、payment）调用，通过 dns_search 可自动补全后缀：
- 例如设为
dns_search: ["svc.cluster.local", "internal"] - 当容器执行
curl auth时，DNS 会依次尝试auth.svc.cluster.local和auth.internal - 与
dns参数搭配使用，能显著减少硬编码完整域名的需求
验证与注意事项
配置生效后，建议进入容器验证实际解析行为：
- 执行
cat /etc/resolv.conf确认 nameserver 和 search 行已写入预期值 - 用
nslookup your-service.internal或dig +short测试目标域名是否返回正确 IP - 注意：若使用 systemd-resolved 或 NetworkManager，宿主机的
/etc/resolv.conf可能是符号链接，Docker 默认不会穿透解析，必须靠dns显式指定
