No DNS in Fedora Podman image on Debian 11

[Francois Gouget]

So I'm trying to use a fedora Podman image on my Debian 11 machine but
for some reason DNS lookups do not seem to be working in the container
environment. Specifically:

$ podman run --rm -it fedora:latest
# dnf install gzip
[...]
Fedora 35 - x86_64 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'fedora':
- Curl error (6): Couldn't resolve host name for
https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64
[getaddrinfo() thread failed to start]

* I have the same issue on two Debian 11 systems (one of which is not
administered by me).

* The container can retrieve web pages with curl if I type in the IP
address. So that confirms it's just the DNS that does not work.

* debian:testing containers have no network or DNS issue. So it's
just fedora:latest that's broken.

* But I also have no issue with fedora:latest if I run it inside a
Fedora 35 VM (Libvirt+QEmu specifically).

* So it's the combination of a Debian 11 host + a Fedora container
that's broken.

* For good measure I tested with an "iptables -I (IN|OUT)PUT -j ACCEPT"
on the host and it makes no difference.

* In the guest /etc/resolv.conf has the domain line and "nameserver
10.0.2.3".

* I see mentions of systemd-resolved on the Internet but I see no trace
of systemd in the Fedora container. I don't know how to specifically
test whever DNS lookups go through systemd-resolved though.


Does anyone know what's up?
Can anyone reproduce this issue?


--
Francois Gouget <fgo...@free.fr> http://fgouget.free.fr/
Un western sans indien c'est comme une police sans serif.
-- John Wayne

[Ulf Volmer]

On 06.11.21 01:46, Francois Gouget wrote:
>
> So I'm trying to use a fedora Podman image on my Debian 11 machine but
> for some reason DNS lookups do not seem to be working in the container
> environment. Specifically:
>
> $ podman run --rm -it fedora:latest
> # dnf install gzip
> [...]
> Fedora 35 - x86_64 0.0 B/s | 0 B 00:00
> Errors during downloading metadata for repository 'fedora':
> - Curl error (6): Couldn't resolve host name for

> Does anyone know what's up?
> Can anyone reproduce this issue?

Yes, I can reproduce this issue.
No issue with fedora:34. But I have no idea what is going wrong here.

Best regards
Ulf

[Ulf Volmer]

If I watch the logs on the host, I see

Nov 07 23:21:39 deb11-p330 audit[910]: SECCOMP auid=1000 uid=1000
gid=1000 ses=1 subj==unconfined pid=910 comm="dnf"
exe="/usr/bin/python3.10" sig=0 arch=c000003e syscall=435 compat=0
ip=0x7f942d6f268d code=0x50000
Nov 07 23:21:39 deb11-p330 kernel: audit: type=1326
audit(1636323699.292:2): auid=1000 uid=1000 gid=1000 ses=1
subj==unconfined pid=910 comm="dnf" exe="/usr/bin/python3.10" sig=0
arch=c000003e syscall=435 compat=0 ip=0x7f942d6f268d code=0x50000

for the fedora:35 container. I did not see this messages with the
fedora:34 container.

Best regards
Ulf

[Ulf Volmer]

On 07.11.21 23:24, Ulf Volmer wrote:
> On 07.11.21 22:28, Ulf Volmer wrote:
>> On 06.11.21 01:46, Francois Gouget wrote:
>>>
>>> So I'm trying to use a fedora Podman image on my Debian 11 machine but
>>> for some reason DNS lookups do not seem to be working in the container
>>> environment. Specifically:
>>>
>>> $ podman run --rm -it fedora:latest
>>> # dnf install gzip
>>> [...]
>>> Fedora 35 - x86_64                                        0.0  B/s |
>>> 0  B     00:00
>>> Errors during downloading metadata for repository 'fedora':
>>>     - Curl error (6): Couldn't resolve host name for
>>
>>> Does anyone know what's up?
>>> Can anyone reproduce this issue?

podman run --rm --security-opt=seccomp=unconfined -it fedora:latest

solves the issue for me.

Best regards
Ulf

[Francois Gouget]

On Sun, 7 Nov 2021, Ulf Volmer wrote:
[...]

> podman run --rm --security-opt=seccomp=unconfined -it fedora:latest
>
> solves the issue for me.

That does work. Thanks!

Today I also found that this is actually a known issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995777

It indicates that this is going to hit all Linux containers using
glibc >= 2.33. Fedora 35 is just the first casualty.

The upstream bug that's referenced there also provides a fix and that
has been integrated in the Podman that's in Debian Testing.
(I checked that there is no issue on Debian Testing)

However I don't know how to convert the 'correct' fix into something
usable with the Debian 11 Podman; and the Debian Testing Podman (3.4) is
not easily installable on Debian 11 (needs a newer libc). So until a fix
makes its way into Debian 11 your workaround will be quite useful.
So thanks again.

--
Francois Gouget <fgo...@free.fr> http://fgouget.free.fr/

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"