Hi everyone,
I'm running Pi-hole and Unbound in separate containers managed by Podman, with network connectivity handled via pasta.
The containers are rootless. I have minimalistic networking, just an isolated network space (no podman network create).
I do not need containers to communicate directly with each other by hostname or IP - so communication is via localhost (127.0.0.1) from the container's point of view.
Here is the pasta process :
/usr/bin/pasta --config-net -t 1053-1053:53-53 -t 1443-1443:443-443 -t 5335-5335:5335-5335 -u 1053-1053:53-53 -u 5335-5335:5335-5335 --dns-forward 169.254.1.1 -T none -U none --no-map-gw --quiet --netns /run/user/1000/netns/netns-a271122e-8dc5-5f50-7dde-42c0ddedef75 --map-guest-addr 169.254.1.2
In my Pi-hole container, I'm using the upstream DNS setting:
127.0.0.1#5335
Unbound is listening on the host's loopback at port 5335.
DNS resolution is working correctly overall, but occasionally I see warnings in Pi-hole logs like:
Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
These seem harmless (no visible resolution issues), but I'm wondering:
What is the recommended configuration for Pi-hole's upstream DNS when using pasta to connect to Unbound container?
More specifically:
- Should I use 127.0.0.1#5335 or 169.254.1.1#5335 (the host address from the container's view via pasta)?
- Are there any known limitations or caveats when using Pi-hole + Unbound over a pasta-based bridge?
Thanks
I'm not familiar with pasta nor with podman, but 127.0.0.1 in a container usually refers to just that container's environment, and you'd want unbound to accept DNS requests from outside its own container.
Thus, using 127.0.0.1 may only work if pasta/podman starts your containers with host system access.
In general, I would also try to avoid IPv4 LLAs (169.254.0.0/16), as those are meant to show up only as a fallback, when all other methods of IP address acquisition have failed, and 169.254.1.1 often would be the link's router.
If the respective link would be something like pasta/podman's virtual interface, that link-local communication may also mean that only machines connected to pasta/podman's internal network would be able to send DNS requests towards unbound.
For your specific case, however, where your Pi-hole container is your unbound container's only client on that same pasta/podman link, this may suffice.
Thanks, You confirmed my reasoning. I used 127.0.0.1#5335 precisely because in my setup containers communication is based on host system - I've not created a dedicated network.
Probably macvlan or ipvlan would have been a better solution, but I wanted to keep it simple.
The pasta is still quite mysterious to me though. That addressing for --map-guest-addr and for --dns-forward that I showed as process parameters is the default - I didn't set that IPs in any way.
So far everything works well, but I wonder if I should not use these addresses for communication somehow...
Pasta is a fairly new stack, so I think more users may be interested in this type of setup.
Let's leave this thread open for a while, perhaps someone will add some interesting observations.