buildah: podman-build network fails DNS lookups; podman-run works

Description

When using a VPN (OpenVPN), DNS lookups fail inside of podman build, but work inside of podman run. Routing works (dig outside of the container and use that IP inside), so I think some UDP tables might not be hooked up properly?

Steps to reproduce the issue:

  1. Set up a VPN in a network namespace (so it is the only available connection)
  2. podman build fails DNS lookups
  3. podman run -it $previous_image_cache works just fine

Describe the results you received:

DNS lookup failure (timeout)

Describe the results you expected:

DNS lookup success.

Output of rpm -q buildah or apt list buildah:

buildah-1.16.2-1.fc33.x86_64

Output of buildah version:

Version:         1.16.2
Go Version:      go1.15
Image Spec:      1.0.1-dev
Runtime Spec:    1.0.2-dev
CNI Spec:        0.4.0
libcni Version:  
image Version:   5.5.2
Git Commit:      
Built:           Wed Dec 31 19:00:00 1969
OS/Arch:         linux/amd64

Output of podman version if reporting a podman build issue:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.15.2
Built:        Wed Oct  7 12:21:20 2020
OS/Arch:      linux/amd64

Output of cat /etc/*release:

Fedora release 33 (Thirty Three)
NAME=Fedora
VERSION="33 (Thirty Three)"
ID=fedora
VERSION_ID=33
VERSION_CODENAME=""
PLATFORM_ID="platform:f33"
PRETTY_NAME="Fedora 33 (Thirty Three)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:33"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=33
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=33
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
Fedora release 33 (Thirty Three)
Fedora release 33 (Thirty Three)

Output of uname -a:

Linux erythro 5.8.16-300.fc33.x86_64 #1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

<Fedora default>

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 22 (13 by maintainers)

Commits related to this issue

Most upvoted comments

@Luap99 @mheon Any update on this?

My podman is experiencing similar symptoms; podman build has a DNS error (on a RUN yum install command) but if I build without that and then run the container and execute the command manually it works.

I am not using OpenVPN, but this is a corporate environment so I’m not sure if some combination of networking/firewall is causing this. Host is a RHEL8 server.

This affects podman 2.2.1 and 3.0.2-dev

I take a look.

A friendly reminder that this issue had no activity for 30 days.

A friendly reminder that this issue had no activity for 30 days.

By “the running container” - is that a Podman container, or inside a build container via a RUN instruction?

That refers to the former. I updated my comment to include the commands to make it clearer.

@rhatdan Just tried that. With that RUN command (using podman build) I can see something like this:

[user@hostmachine]$ podman build --force-rm -t my_image .....
...
STEP 12: RUN cat /etc/resolv.conf
search example.com abc.example.com xyz.example.com
--> b2bf9332152
STEP 13: ..............
...

Inside the running container we have:

[user@hostmachine]$ podman run my_image cat /etc/resolv.conf
search example.com abc.example.com xyz.example.com
nameserver 10.0.2.3
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

On the host machine we have:

[user@hostmachine]$ cat /etc/resolv.conf
search example.com abc.example.com xyz.example.com
nameserver <internal IP>
nameserver <internal IP>
nameserver <internal IP>
nameserver <internal IP>

In all 3 snippets example.com is actually a corporate domain, and in the 3rd snippet the internal IPs are valid internal DNS servers.

I don’t know enough to say that the first snippet is messed up or not.