Running Pi-hole + Unbound on rootless Podman: two findings that may help others
After deploying Pi-hole v6 with Unbound on rootless Podman (custom bridge network using netavark), I spent several hours debugging two issues that eventually turned out to have different root causes.
I hope this summary helps anyone building a similar setup.
Environment
-
Oracle Linux 10
-
Podman rootless
-
netavark
-
Custom bridge network
-
Pi-hole v6
-
Unbound running in a separate container
Architecture:
Clients
→ Pi-hole
→ Unbound
→ Internet
Unbound is also authoritative for a local zone (b-thinking.com) and the corresponding reverse zone (192.168.10.0/24).
1. All clients appeared as "pi.hole"
Pi-hole showed almost all DNS requests as originating from pi.hole instead of the real client IP.
After creating a minimal Python UDP server inside another container, we verified that every UDP packet arrived with the source address rewritten from the original LAN client (e.g. 192.168.10.100) to the Podman bridge address (10.92.0.x).
The Podman maintainers confirmed this is expected behaviour of the current rootlessport port forwarder:
any rootless custom network used rootlessport as port forwarder which always looses the source ip, that is/was by design.
They also pointed out that Podman 6 introduces an experimental alternative:
[network]
rootless_port_forwarder="pasta"
Reference:
https://github.com/podman-container-tools/podman/issues/29064
This is therefore not a Pi-hole issue, but it may help other users deploying Pi-hole on rootless Podman.
2. Reverse lookups returned NXDOMAIN
My local reverse zone was hosted in Unbound.
Direct queries to Unbound worked correctly:
dig @10.92.0.20 -p 5053 -x 192.168.10.2
returned:
PTR leia.b-thinking.com.
However, querying Pi-hole returned NXDOMAIN:
dig @192.168.10.2 -x 192.168.10.2
The reason was the Pi-hole DNS setting:
Never forward reverse lookups for private IP ranges
When enabled, Pi-hole answers private reverse lookups itself (NXDOMAIN if not present in /etc/hosts or DHCP leases) and never forwards them to the upstream resolver.
Disabling this option solved the issue immediately.
This behaviour is perfectly correct, but users whose upstream resolver (for example Unbound) is authoritative for private reverse zones may not immediately realise why their PTR records never reach the upstream.
Perhaps the description of this option could explicitly mention this scenario.
Hopefully this helps anyone deploying the same architecture.