I'm running a containerized DNS server (BIND9 inside a Podman container) with rootless Podman, and I can't get host-to-container connectivity to work over loopback for a published port, even though everything else about the setup checks out.
Setup
bashpodman run -d --name bind-sec
-p 30053:53/tcp -p 30053:53/udp
-v /var/cache/bind-sec:/var/cache/bind
my-bind-image:latest
podman ps shows the port mapping correctly:
PORTS
0.0.0.0:30053->53/tcp, 0.0.0.0:30053->53/udp
What works
The container itself is healthy — podman logs shows BIND fully started, zones loaded, listening on port 53 internally.
Querying the container's own internal IP directly from inside the container's network namespace works fine.
ss -tlnp on the host shows something listening on 0.0.0.0:30053 (confirmed via lsof -i :30053 that it's the container's conmon/proxy process, not a stray process).
Other containers I run with the same -p pattern (e.g., a basic httpd container on port 8080) do work correctly over loopback — curl http://127.0.0.1:8080/ succeeds normally for those.
What fails
bashdig @127.0.0.1 -p 30053 example.com
;; communications error to 127.0.0.1#30053: timed out
This fails consistently, both from the host itself and (with appropriate firewall rules in place) from other hosts on the same subnet querying :30053.
What I've tried
Confirmed firewall (nftables) rules explicitly allow the port on both iif "lo" and the regular network interface — ruled out as the cause since the same symptom persists with or without those rules.
Tried both default bridge networking and --network=slirp4netns:allow_host_loopback=true — same timeout in both modes.
Tried running the same container with sudo (rootful) instead of rootless — same timeout persists.
Confirmed no orphaned/leftover container processes are holding the port from a previous run.
My question
Why would a UDP/TCP port published via -p work fine for an HTTP container (httpd on 8080) but consistently time out for a DNS container on a different port, using the identical -p host:container syntax and the same Podman version/host? Is there something DNS/UDP-specific about rootless Podman's port-forwarding (rootlessport) that behaves differently from a simple TCP HTTP service, even when both are nominally "just a published port"?
Environment
Ubuntu 24.04 LTS
Podman (rootless, default config)
nftables firewall (rules confirmed not to be the blocker)
I'm running a containerized DNS server (BIND9 inside a Podman container) with rootless Podman, and I can't get host-to-container connectivity to work over loopback for a published port, even though everything else about the setup checks out.
Setup
bashpodman run -d --name bind-sec
-p 30053:53/tcp -p 30053:53/udp
-v /var/cache/bind-sec:/var/cache/bind
my-bind-image:latest
podman ps shows the port mapping correctly:
PORTS
0.0.0.0:30053->53/tcp, 0.0.0.0:30053->53/udp
What works
The container itself is healthy — podman logs shows BIND fully started, zones loaded, listening on port 53 internally.
Querying the container's own internal IP directly from inside the container's network namespace works fine.
ss -tlnp on the host shows something listening on 0.0.0.0:30053 (confirmed via lsof -i :30053 that it's the container's conmon/proxy process, not a stray process).
Other containers I run with the same -p pattern (e.g., a basic httpd container on port 8080) do work correctly over loopback — curl http://127.0.0.1:8080/ succeeds normally for those.
What fails
bashdig @127.0.0.1 -p 30053 example.com
;; communications error to 127.0.0.1#30053: timed out
This fails consistently, both from the host itself and (with appropriate firewall rules in place) from other hosts on the same subnet querying :30053.
What I've tried
Confirmed firewall (nftables) rules explicitly allow the port on both iif "lo" and the regular network interface — ruled out as the cause since the same symptom persists with or without those rules.
Tried both default bridge networking and --network=slirp4netns:allow_host_loopback=true — same timeout in both modes.
Tried running the same container with sudo (rootful) instead of rootless — same timeout persists.
Confirmed no orphaned/leftover container processes are holding the port from a previous run.
My question
Why would a UDP/TCP port published via -p work fine for an HTTP container (httpd on 8080) but consistently time out for a DNS container on a different port, using the identical -p host:container syntax and the same Podman version/host? Is there something DNS/UDP-specific about rootless Podman's port-forwarding (rootlessport) that behaves differently from a simple TCP HTTP service, even when both are nominally "just a published port"?
Environment
Ubuntu 24.04 LTS
Podman (rootless, default config)
nftables firewall (rules confirmed not to be the blocker)