When BuildKit is launched as a Docker container (either via the Docker container driver or via docker run and the remote driver) with "host" networking enabled (--network=host) on a host OS using systemd-resolved the incorrect DNS settings (/etc/resolv.conf) will be passed to build containers. Specifically, instead of using the host/system DNS settings it will fallback to the default configuration:
If it detects systemd-resolved it attempts to instead read/use the file at /run/systemd/resolve/resolv.conf, however this file will not exist within the running Docker container as it is running within a mount namespace. As a result, BuildKit will fallback to the default DNS servers (Google) which may not be reachable in the environment.
As a work-around, the host resolv.conf files can be mounted into the running buildkit container which will result in a functional build environment:
When BuildKit is launched as a Docker container (either via the Docker container driver or via
docker run
and the remote driver) with "host" networking enabled (--network=host
) on a host OS usingsystemd-resolved
the incorrect DNS settings (/etc/resolv.conf
) will be passed to build containers. Specifically, instead of using the host/system DNS settings it will fallback to the default configuration:This issue occurs due to the use of resolveconf.Path which implements custom logic to detect the use of
systemd-resolved
: https://github.com/moby/moby/blob/de5c9cf0b96e4e172b96db54abababa4a328462f/libnetwork/internal/resolvconf/resolvconf_path.go#L50-L51If it detects
systemd-resolved
it attempts to instead read/use the file at/run/systemd/resolve/resolv.conf
, however this file will not exist within the running Docker container as it is running within a mount namespace. As a result, BuildKit will fallback to the default DNS servers (Google) which may not be reachable in the environment.As a work-around, the host
resolv.conf
files can be mounted into the running buildkit container which will result in a functional build environment: