A dotnet restore failure during a Docker build can come from DNS, network access, proxy settings, certificates, feed credentials, or a package problem. In my 2021 setup, networking was the issue. The error message alone does not identify DNS as the cause.
First check which daemon and builder you are using and read the restore error. A complete build command includes -t for the image tag and a build context, here the current directory:
docker build --network=default -t my-image .Update, 15 October 2026: the old example omitted both pieces and incorrectly suggested trying every network ID. Modern BuildKit documents default, none, and host modes for build steps. Host networking is platform- and builder-dependent and may require an entitlement; it is not a portable fix for Windows container builds. See Docker’s build network documentation.
If a DNS lookup fails inside the relevant container environment, configure a DNS server that is reachable and appropriate for that network. Public resolvers may not resolve private package feeds. Do not copy 10.1.2.3 from the old screenshot unless that is actually your DNS server.
For Docker Engine, the usual configuration file is /etc/docker/daemon.json on Linux or C:\ProgramData\docker\config\daemon.json for a Windows daemon. Docker Desktop exposes engine settings in its UI. Merge the setting into the existing JSON rather than replacing unrelated settings. For example, the following uses Google’s public resolver and is suitable only where that resolver is allowed and sufficient:
{
"dns": ["8.8.8.8"]
}Apply the configuration and restart the affected daemon if required, allowing for interruption to running containers. Then repeat the failed lookup and build. If the builder has its own network configuration, changing the engine’s DNS may not affect it. A successful retry in one setup does not establish the cause in another.
Originally published on blog.yavuz.support: https://blog.yavuz.support/docker-build-fails-because-it-has-no-internet.