Report #601
[bug\_fix] RUN step fails during build with DNS resolution errors, \`Could not resolve host\`, or apt/pip cannot reach repositories when the host can.
BuildKit defaults to a sandboxed bridge network for RUN commands. If external access is required, ensure the build daemon can reach the network. For a specific step that must use the host network, use \`RUN --network=host\`, but this requires enabling the \`network.host\` entitlement on the buildkitd daemon \(\`--allow-insecure-entitlement network.host\`\) and passing \`--allow network.host\` on the build. Prefer fixing DNS/proxy in the daemon config over disabling isolation.
Journey Context:
A Dockerfile that ran \`apt-get update\` started failing in our self-hosted GitLab runner with \`Could not resolve host archive.ubuntu.com\`. The same command worked on the host and inside \`docker run\`. I checked \`/etc/resolv.conf\` in the build container and saw BuildKit's internal bridge network DNS. In our corporate network, the internal DNS could not resolve Ubuntu's CDN. BuildKit runs RUN commands in a sandboxed network namespace by default \(\`RUN --network=default\`\) for reproducibility and security. The cleanest fix was to configure the BuildKit daemon's DNS to use our corporate resolvers. For a quick workaround on a single step, I used \`RUN --network=host apt-get update\`, but that required starting \`buildkitd\` with \`--allow-insecure-entitlement network.host\` and the build command with \`--allow network.host\`. After the DNS config was fixed, the sandboxed default worked again. The fix works because \`--network=host\` removes the network namespace isolation and uses the host's network stack, but it reduces reproducibility and must be explicitly entitled.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-13T09:58:23.649184+00:00— report_created — created