Docker Pi-hole 容器中IPv6地址解析问题的分析与解决

问题背景

在使用Docker部署Pi-hole作为网络DNS服务器时，用户遇到了一个关于IPv6地址解析的特殊问题。当查询主机名时，Pi-hole返回的是容器内部的IPv6地址（fd3b:2b2d:793a::2），而不是预期的外部主机IPv6地址（fd00::3ee9:3bb4:e994:500c）。这个问题在IPv4环境下表现正常，但在IPv6环境下出现了异常。

环境配置

用户使用的是Raspberry Pi 4B硬件平台，运行Rasbian操作系统，采用Docker Compose方式部署Pi-hole容器。关键配置包括：

• 容器网络模式：自定义桥接网络，启用了IPv6支持
• 环境变量设置了主机IPv4和IPv6地址：
  • FTLCONF_dns_reply_host_IPv4: "192.168.178.2"
  • FTLCONF_dns_reply_host_IPv6: "fd00::3ee9:3bb4:e994:500c"
• 端口映射将容器的DNS服务暴露给主机网络

问题现象

通过nslookup工具进行测试时发现：

1. 从容器内部查询主机名时，返回的是容器内部的IPv6地址
2. 从主机或其他网络设备查询时，同样返回容器内部的IPv6地址
3. IPv4地址解析正常，返回的是配置的外部主机地址
4. 反向DNS查询（PTR记录）却能正确解析到外部主机IPv6地址

根本原因分析

经过排查，发现问题的根源在于：

1. Docker容器内部的/etc/hosts文件自动包含了容器自身的IPv6地址映射
2. Pi-hole的DNS服务在处理IPv6查询时，优先使用了容器内部的地址记录
3. 虽然用户配置了外部IPv6地址，但Pi-hole默认不会强制覆盖容器内部的地址记录
4. IPv4环境下由于配置了强制回复（隐含行为），所以表现正常

解决方案

通过添加以下环境变量配置，强制Pi-hole使用指定的IPv6地址进行回复：

environment:
  FTLCONF_dns_reply_host_force6: true

这个配置明确告诉Pi-hole的FTL DNS服务，在响应主机名查询时，强制使用配置的外部IPv6地址，而忽略容器内部的地址记录。

配置建议

对于需要在Docker中部署Pi-hole并正确处理IPv6地址的场景，建议采用以下完整配置：

environment:
  FTLCONF_dns_reply_host_IPv4: "192.168.178.2"
  FTLCONF_dns_reply_host_IPv6: "fd00::3ee9:3bb4:e994:500c"
  FTLCONF_dns_reply_host_force4: true
  FTLCONF_dns_reply_host_force6: true

技术原理

Pi-hole的FTL DNS引擎在处理本地主机名查询时，会按照以下优先级决定返回的IP地址：

1. 首先检查是否有强制回复配置（force4/force6）
2. 如果没有强制配置，则检查容器内部的网络配置
3. 最后才会考虑用户配置的回复地址

在IPv6环境下，由于Docker自动配置了容器IPv6地址到/etc/hosts，且默认不强制覆盖，导致了这个问题。而IPv4环境下由于历史原因和向后兼容性考虑，Pi-hole有隐含的强制行为。

总结

这个案例展示了在容器化环境中处理网络配置时需要特别注意的细节。特别是当容器需要代表主机对外提供服务时，网络地址的映射和响应需要明确配置。通过理解Pi-hole的地址回复机制，我们可以更好地控制DNS查询的响应行为，确保网络服务按预期工作。