<p>At a command prompt run <code>ipconfig /all</code> and look for a <code>DNS Servers</code> line in the output with something that looks like an IPv4 address. That's your host machine's DNS server(s).</p>
<p>Edit <code>C:\ProgramData\Docker\config\daemon.json</code> and add a <code>dns</code> entry with that IPv4 address. For example, if your DNS Server is 192.10.0.2 and 8.8.8.8 is Google's DNS as a backup:</p>
<pre><code>{
    &quot;dns&quot;: [&quot;192.10.0.2&quot;, &quot;8.8.8.8&quot;]
}
</code></pre>
<p>Now restart Docker Desktop and the remote URLs can be resolved by Docker, either at build or runtime.</p>
<p>This solution came from Faithful Anere at <a href="https://medium.com/@faithfulanere/solved-docker-build-could-not-resolve-archive-ubuntu-com-apt-get-fails-to-install-anything-9ea4dfdcdcf2" rel="nofollow noreferrer">https://medium.com/@faithfulanere/solved-docker-build-could-not-resolve-archive-ubuntu-com-apt-get-fails-to-install-anything-9ea4dfdcdcf2</a></p>
<p><strong>UPDATE 2024</strong></p>
<p>You now need to open Docker Desktop and go to Settings &gt; Docker Engine to update this setting. If you edit the file directly it gets overwritten when you restart Docker.</p>
<p><strong>UPDATE 2, 2024</strong></p>
<p>You can edit the file at <code>%userprofile%\.docker\daemon.json</code> and then restart Docker. Using Docker Desktop to modify the file may lose your changes when Docker Desktop is restarted.</p>

CC BY-SA 4.0
2019-12-16T18:40:08.193Z
2024-11-21T11:46:43.223Z
2024-11-21T11:46:43.223Z
sussexrick
<p>As comments are transient, here's some info for the next person trying to solve this problem. Please feel free to edit this answer to provide more details, unless you're a Docker for Windows pro, in which case please give a better answer :D</p>

<p>I went to demo the problem for my IT group after having changed my NIC on my VM to bridged and adding my thunderbolt adapter. As there are security systems in place, I realized I needed to add the security software to my VM, but as it isn't joined to the domain, that was a problem. Switching it back to NAT on the wifi adapter, and then going to demo the problem in my Windows 2016 VM somehow magically made it start working.</p>

<p>Same network. Same VM configuration. Same software and host, no changes to anything I can track.</p>

<p>Having checked Get-ContainerNetwork or Get-WinNat showing nothing, I really had been at my end of diagnostics. Changing that NIC adapter and then changing it back apparently caused something to reset. Good times.</p>

<p>So, I don't have a solid answer, but I have a good workaround for the next person stuck in my shoes, which, given my track record of StackExchange questions and answers, will be me. But I hope it helps you out too, random internet asker.</p>

<hr>

<p>And an XKCD tax, for those impossible to solve problems.</p>

<p><a href="https://xkcd.com/979/" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZAhuo.png" alt="XKCD Comic Link to &quot;Wisdom of the ancients&quot;"></a></p>

CC BY-SA 3.0
2017-09-28T05:38:20.203Z
According to this description, I'm tempted to put a bill on a DNS cache cleared by the shut/no shut of the network stack as Windows have this kind idea to cache negative request also. If it comes to happen again,  may worth trying a `ipconfig /flushdns` on the windows host
Tensibai
CC BY-SA 3.0
2018-01-02T23:08:39.467Z
Meant to add, the host in this case is OSX, if you mean the base OS hosting everything. If you mean where I'm running the docker container, that's windows.
jcolebrand
CC BY-SA 3.0
2018-01-03T06:22:20.813Z
I mean the windows host, I don't remember *nix based   network stacks caching negative queries
Tensibai
CC BY-SA 3.0
2017-09-27T17:51:39.443Z
2017-09-27T17:51:39.443Z
jcolebrand
<p>I recently had this frustrating problem but I managed to fix it today.</p>
<p>What I did, is in the desktop app on Windows / Mac you can edit the Daemon file. Under Settings in the Docker App under Docker Engine, I added the line at the bottom of the file just above the last curly brace. <code>&quot;dns&quot;: [ &quot;192.168.4.100&quot;, &quot;8.8.8.8&quot; ]</code></p>
<p>This then allows the Docker Containers all that you now build to use your host's DNS server. Technically if you can access: <a href="https://chocolatey.org/install.ps1" rel="nofollow noreferrer">https://chocolatey.org/install.ps1</a> then you should be able to access the choco repository.</p>
<p>I have also built the image in <a href="https://github.com/jasric89/vsts-agent-docker/tree/master/windows/servercore/10.0.14393" rel="nofollow noreferrer">https://github.com/jasric89/vsts-agent-docker/tree/master/windows/servercore/10.0.14393</a> and labeled it in the repo:</p>
<p>microsoft/windowsservercore:10.0.14393.1358</p>
<p>I then set: <code>RUN choco feature enable --name allowGlobalConfirmation</code> before my first Choco Install command, this enables choco to install all the files and not error.</p>
<p>With all that set my Docker File Ran and built the image. Well in my Test Env now testing in my prod env. :)</p>
<p>Links that helped me:</p>
<p><a href="https://github.com/moby/moby/issues/24928" rel="nofollow noreferrer">https://github.com/moby/moby/issues/24928</a>
<a href="https://github.com/jasric89/vsts-agent-docker/blob/master/windows/servercore/10.0.14393/standard/VS2017/Dockerfile" rel="nofollow noreferrer">https://github.com/jasric89/vsts-agent-docker/blob/master/windows/servercore/10.0.14393/standard/VS2017/Dockerfile</a>
<a href="https://docs.chocolatey.org/en-us/troubleshooting" rel="nofollow noreferrer">https://docs.chocolatey.org/en-us/troubleshooting</a>
<a href="https://github.com/moby/moby/issues/25537" rel="nofollow noreferrer">https://github.com/moby/moby/issues/25537</a></p>

CC BY-SA 4.0
2021-04-28T15:20:53.677Z
2021-04-28T15:20:53.677Z
Jason
<p>Try installation instructions from <a href="https://chocolatey.org/install#completely-offline-install" rel="nofollow noreferrer">https://chocolatey.org/install#completely-offline-install</a> (section "Installing behind a proxy"):</p>

<pre><code>    @powershell -NoProfile -ExecutionPolicy Bypass -Command "[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" &amp;&amp; SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
</code></pre>

CC BY-SA 4.0
2018-06-10T08:21:20.213Z
You're answering a different question here, the question is why the container can't resolve internet addresses
Tensibai
CC BY-SA 4.0
2018-06-10T06:12:10.083Z
2018-06-10T06:12:10.083Z
Valerij Klein
<p>The problem appears to be that the Windows images configure DNS to first be the default gateway of the NAT interface, and then the DNS of the host machine.  DNS lookups fail against that first resolver and external access.</p>

<p>Adding <code>--dns 8.8.8.8</code> (or your local resolver) to the CLI seems to work around the problem.</p>

CC BY-SA 3.0
2017-09-28T19:14:42.867Z
That's awesome. Who can get this on a backlog for resolution? :D
jcolebrand
CC BY-SA 4.0
2018-11-08T13:03:27.277Z
@jcolebrand Hi, I am also facing the same issue. I have corporate proxy configuration. Where do we need to add that dns configuration? In daemon.json ?
user2301
CC BY-SA 4.0
2018-11-08T15:04:13.773Z
Did you try on the command as indicated in this answer?
jcolebrand
CC BY-SA 4.0
2018-11-09T13:46:25.497Z
@jcolebrand  Tried with `docker build --dns 8.8.8.8 -t choco .` did not work. Then I added `"dns": ["8.8.8.8"]` in daemon.json did not work.
user2301
CC BY-SA 4.0
2018-11-09T14:12:38.427Z
I thought the dns flag was at run not at build?
jcolebrand
CC BY-SA 3.0
2017-09-28T18:47:17.567Z
2017-09-28T18:47:17.567Z
Steven Murawski
<p>xpost from <a href="https://forums.docker.com/t/cannot-connect-to-chocolatey-org/38745" rel="noreferrer">https://forums.docker.com/t/cannot-connect-to-chocolatey-org/38745</a></p>

<h3>Expected behavior</h3>

<p>I'm running Windows Server 2016 Datacenter (MSDN download) 64 bit - Version 1607 - Build 14393.1715</p>

<p>I'm using Docker For Windows and running Windows Containers.</p>

<p>I figure this is the easiest thing in the world, to do this:</p>

<pre><code>reboot my host machine
docker run -it microsoft/windowsservercore
powershell
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'));
</code></pre>

<p>The expectation is for this to install chocolatey in the container. </p>

<p><em>I'm actually going to be doing this in a dockerfile, but I'm going for minimum working example to get help right now.</em></p>

<p>Here's an actual docker file that fails (it's not so creative, sadly)</p>

<pre><code>FROM microsoft/windowsservercore

SHELL ["Powershell"]

ENV ChocolateyUseWindowsCompression false;
RUN iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'));
</code></pre>

<h3>Actual behavior</h3>

<p>First things first: I'm running this in a Virtualbox VM. Everything else that I want to work works, including but not limited to: internal network connectivity and tests, sql server running, WCF services running against my docker-compose environment, data coming back correctly. All of the things I expect the system to do are working. This is the last-step, fingers crossed :D. The fact that I'm running this in VirtualBox shouldn't matter, since the Hyper-V is working and all my machines are working as expected. I just figure it's worth mentioning.</p>

<pre><code>docker run -it microsoft/windowsservercore
powershell
PS C:\&gt; iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
Exception calling "DownloadString" with "1" argument(s): "The remote name could not be resolved: 'chocolatey.org'"
At line:1 char:1
+ iex ((new-object net.webclient).DownloadString('https://chocolatey.or ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException

PS C:\&gt; ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 339189e8dd56
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : attlocal.net

Ethernet adapter vEthernet (Container NIC 6412b757):

   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physical Address. . . . . . . . . : 00-15-5D-80-E9-2C
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a51b:820e:e45d:fab6%29(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.22.202.147(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 172.22.192.1
   DNS Servers . . . . . . . . . . . : 172.22.192.1
                                       10.0.2.2
   NetBIOS over Tcpip. . . . . . . . : Disabled
</code></pre>

<p>From my host OS (Server 2016) I have this information:</p>

<pre><code>PS C:\docker&gt; ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : WIN-CDPNLUMSTOE
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : attlocal.net

Ethernet adapter vEthernet (HNS Internal NIC) 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : 00-15-5D-80-E5-17
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5939:52e7:aaf3:5b70%9(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.22.192.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 301995357
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (HNS Internal NIC) 3:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-15-5D-B6-45-8D
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::1de4:bff7:36fb:ee92%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.23.128.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 570430813
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-51-5F-6A
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::10de:923b:b866:221d%4(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.2.15(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Friday, August 19, 1881 6:47:42 PM
   Lease Expires . . . . . . . . . . : Tuesday, September 26, 2017 11:15:59 PM
   Default Gateway . . . . . . . . . : 10.0.2.2
   DHCP Server . . . . . . . . . . . : 10.0.2.2
   DHCPv6 IAID . . . . . . . . . . . : 50855975
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : 10.0.2.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{C420BD56-5715-49BF-9382-5EA99AA48563}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{70EA4F39-FE0F-4040-B718-ACAC00765808}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.attlocal.net:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #7
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
PS C:\docker&gt;
</code></pre>

<h3>Information</h3>

<p>DockerDebugInfo.ps1 output: <a href="https://gist.github.com/jcolebrand/170673e45bf8a659552f22f2071c30d6" rel="noreferrer">https://gist.github.com/jcolebrand/170673e45bf8a659552f22f2071c30d6</a></p>

<h3>System information</h3>

<p>Running Windows Server Datacenter (MSDN download) 64 bit - Version 1607 - Build 14393.1715</p>

<pre><code>PS C:\docker&gt; docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:57:19 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.24)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:59:47 2017
 OS/Arch:      windows/amd64
 Experimental: true
</code></pre>

<p><em>If, for any forsaken reason this is important, the host OS does need to be activated. I'm doing this in a one-shot dev environment so wasn't particularly worried about activating the VM just yet. I can't fathom how this is important. Especially since everything else "just works".</em></p>

CC BY-SA 3.0
2017-09-26T16:05:31.750Z
It seems like there is a similar issue posted here https://github.com/docker/for-win/issues/427 Try stopping and starting the docker service.
Preston Martin
CC BY-SA 3.0
2017-09-26T16:06:19.997Z
Thanks @PrestonM I did that many times. And rebooted the computer. And get-netnat|remove-netnat
jcolebrand
CC BY-SA 3.0
2017-09-26T16:15:29.373Z
running `Stop-Service docker; Get-ContainerNetwork | Remove-ContainerNetwork -Force; Start-Service docker` presents a couple issues. no service found with name docker. no container networks found with Get-ContainerNetwork
jcolebrand
CC BY-SA 3.0
2017-09-26T16:17:01.927Z
where are you running the command from? Virtualbox, or Windows Server?
Preston Martin
CC BY-SA 3.0
2017-09-26T16:19:46.433Z
@PrestonM A little confused. Let me recap my setup: OSX Host -> VirtualBox -> Windows Server 2016 -> Docker for Windows -> container. The stack is all running on Hyper-V layers, and I can do everything else I ask on my containers, including internal network communication between apps and a local database instance (microsoft/mssql-server-windows-developer) so everything that I want to do is fine. The commands are being issued in a powershell term on the container. The Server2016 can reach the internet fine.
jcolebrand
CC BY-SA 3.0
2017-09-26T16:32:36.670Z
It seems this is similar to [No external network connectivity from inside Docker container](https://forums.docker.com/t/no-external-network-connectivity-from-inside-docker-container/8045). Many suggestions, including changing DNS server, are mentioned.
Andrew T.
CC BY-SA 3.0
2017-09-26T16:36:44.163Z
Gotcha. I skipped over the OSX part and thought you were running virtual box on server 2016
Preston Martin
CC BY-SA 3.0
2017-09-26T16:42:21.233Z
@AndrewT. that issue is different in my expectation because that's the HOST not being able to talk to the internet, no? I can pull images just fine.
jcolebrand
CC BY-SA 3.0
2017-09-26T17:32:21.070Z
So here's the best part today: I goto demonstrate for IT. So that we can troubleshoot what it MIGHT be. NAT on NAT (vmhost -> docker container), so direct network cable, etc. AND IT WORKS. It just works. We changed nothing. So I'm gonna try and get back to failure reproducible.
jcolebrand
CC BY-SA 3.0
2017-09-26T17:56:15.343Z
@jcole so could it be your usual network connectivity from osx causing problem? How is the windows guest networking configured? Nat or bridge? (reading on phone I may have missed the information)
Tensibai
CC BY-SA 3.0
2017-09-26T18:23:18.783Z
@Tensibai on the OSX -> VirtualBox it's NAT, I was getting ready to switch to bridge but then there were other issues so ... I was testing with them on NAT to demonstrate the issue.
jcolebrand
CC BY-SA 3.0
2017-09-27T07:38:35.593Z
I suspect a glitch on the hyper-v side for DNS forwarding, or maybe just a negative cache from a request done at a time there was no outside connectivity, windows has this bad habit of caching NXDOMAIN answers.
Tensibai
CC BY-SA 3.0
2017-09-27T13:24:17.027Z
That starts to make sense that it would have been from a layer mismatch, but I was also on my home WiFi with the same laptop and the same issue. I hoped it would resolve itself. Looks like toggling the host VMs nic ended up resolving the problem.
jcolebrand
<docker><windows>
Cannot connect to chocolatey.org or any other internet site from within container
jcolebrand
# Cannot connect to chocolatey.org or any other internet site from within container

(Asked by: username_0 on 2017-09-26)

xpost from https://forums.docker.com/t/cannot-connect-to-chocolatey-org/38745
Expected behavior
I'm running Windows Server 2016 Datacenter (MSDN download) 64 bit - Version 1607 - Build 14393.1715
I'm using Docker For Windows and running Windows Containers.
I figure this is the easiest thing in the world, to do this:
reboot my host machine
docker run -it microsoft/windowsservercore
powershell
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'));

The expectation is for this to install chocolatey in the container. 
I'm actually going to be doing this in a dockerfile, but I'm going for minimum working example to get help right now.
Here's an actual docker file that fails (it's not so creative, sadly)
FROM microsoft/windowsservercore

SHELL ["Powershell"]

ENV ChocolateyUseWindowsCompression false;
RUN iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'));

Actual behavior
First things first: I'm running this in a Virtualbox VM. Everything else that I want to work works, including but not limited to: internal network connectivity and tests, sql server running, WCF services running against my docker-compose environment, data coming back correctly. All of the things I expect the system to do are working. This is the last-step, fingers crossed :D. The fact that I'm running this in VirtualBox shouldn't matter, since the Hyper-V is working and all my machines are working as expected. I just figure it's worth mentioning.
docker run -it microsoft/windowsservercore
powershell
PS C:\> iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
Exception calling "DownloadString" with "1" argument(s): "The remote name could not be resolved: 'chocolatey.org'"
At line:1 char:1
+ iex ((new-object net.webclient).DownloadString('https://chocolatey.or ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException

PS C:\> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 339189e8dd56
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : attlocal.net

Ethernet adapter vEthernet (Container NIC 6412b757):

   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physical Address. . . . . . . . . : 00-15-5D-80-E9-2C
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a51b:820e:e45d:fab6%29(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.22.202.147(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 172.22.192.1
   DNS Servers . . . . . . . . . . . : 172.22.192.1
                                       10.0.2.2
   NetBIOS over Tcpip. . . . . . . . : Disabled

From my host OS (Server 2016) I have this information:
PS C:\docker> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : WIN-CDPNLUMSTOE
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : attlocal.net

Ethernet adapter vEthernet (HNS Internal NIC) 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : 00-15-5D-80-E5-17
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5939:52e7:aaf3:5b70%9(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.22.192.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 301995357
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (HNS Internal NIC) 3:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-15-5D-B6-45-8D
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::1de4:bff7:36fb:ee92%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.23.128.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 570430813
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-51-5F-6A
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::10de:923b:b866:221d%4(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.2.15(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Friday, August 19, 1881 6:47:42 PM
   Lease Expires . . . . . . . . . . : Tuesday, September 26, 2017 11:15:59 PM
   Default Gateway . . . . . . . . . : 10.0.2.2
   DHCP Server . . . . . . . . . . . : 10.0.2.2
   DHCPv6 IAID . . . . . . . . . . . : 50855975
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-4E-0C-48-08-00-27-51-5F-6A
   DNS Servers . . . . . . . . . . . : 10.0.2.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{C420BD56-5715-49BF-9382-5EA99AA48563}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{70EA4F39-FE0F-4040-B718-ACAC00765808}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.attlocal.net:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : attlocal.net
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #7
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
PS C:\docker>

Information
DockerDebugInfo.ps1 output: https://gist.github.com/username_0/170673e45bf8a659552f22f2071c30d6
System information
Running Windows Server Datacenter (MSDN download) 64 bit - Version 1607 - Build 14393.1715
PS C:\docker> docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:57:19 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.06.2-ce
 API version:  1.30 (minimum version 1.24)
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 19:59:47 2017
 OS/Arch:      windows/amd64
 Experimental: true

If, for any forsaken reason this is important, the host OS does need to be activated. I'm doing this in a one-shot dev environment so wasn't particularly worried about activating the VM just yet. I can't fathom how this is important. Especially since everything else "just works".

**Tags:** docker, windows

> **Comments:**
> **username_1**: It seems like there is a similar issue posted here https://github.com/docker/for-win/issues/427 Try stopping and starting the docker service.  
> **username_0**: Thanks @PrestonM I did that many times. And rebooted the computer. And get-netnat|remove-netnat  
> **username_0**: running `Stop-Service docker; Get-ContainerNetwork | Remove-ContainerNetwork -Force; Start-Service docker` presents a couple issues. no service found with name docker. no container networks found with Get-ContainerNetwork  
> **username_1**: where are you running the command from? Virtualbox, or Windows Server?  
> **username_0**: @PrestonM A little confused. Let me recap my setup: OSX Host -> VirtualBox -> Windows Server 2016 -> Docker for Windows -> container. The stack is all running on Hyper-V layers, and I can do everything else I ask on my containers, including internal network communication between apps and a local database instance (microsoft/mssql-server-windows-developer) so everything that I want to do is fine. The commands are being issued in a powershell term on the container. The Server2016 can reach the internet fine.  
> **username_2**: It seems this is similar to [No external network connectivity from inside Docker container](https://forums.docker.com/t/no-external-network-connectivity-from-inside-docker-container/8045). Many suggestions, including changing DNS server, are mentioned.  
> **username_1**: Gotcha. I skipped over the OSX part and thought you were running virtual box on server 2016  
> **username_0**: @AndrewT. that issue is different in my expectation because that's the HOST not being able to talk to the internet, no? I can pull images just fine.  
> **username_0**: So here's the best part today: I goto demonstrate for IT. So that we can troubleshoot what it MIGHT be. NAT on NAT (vmhost -> docker container), so direct network cable, etc. AND IT WORKS. It just works. We changed nothing. So I'm gonna try and get back to failure reproducible.  
> **username_3**: @jcole so could it be your usual network connectivity from osx causing problem? How is the windows guest networking configured? Nat or bridge? (reading on phone I may have missed the information)  
> **username_0**: @username_3 on the OSX -> VirtualBox it's NAT, I was getting ready to switch to bridge but then there were other issues so ... I was testing with them on NAT to demonstrate the issue.  
> **username_3**: I suspect a glitch on the hyper-v side for DNS forwarding, or maybe just a negative cache from a request done at a time there was no outside connectivity, windows has this bad habit of caching NXDOMAIN answers.  
> **username_0**: That starts to make sense that it would have been from a layer mismatch, but I was also on my home WiFi with the same laptop and the same issue. I hoped it would resolve itself. Looks like toggling the host VMs nic ended up resolving the problem.  

---

## 5 answers

### Answer by username_7 on 2017-09-28. Score: 7 | Accepted answer

The problem appears to be that the Windows images configure DNS to first be the default gateway of the NAT interface, and then the DNS of the host machine. DNS lookups fail against that first resolver and external access.

Adding `--dns 8.8.8.8` (or your local resolver) to the CLI seems to work around the problem.

> **Comments:**
> **username_0**: That's awesome. Who can get this on a backlog for resolution? :D  
> **username_8**: @username_0 Hi, I am also facing the same issue. I have corporate proxy configuration. Where do we need to add that dns configuration? In daemon.json ?  
> **username_0**: Did you try on the command as indicated in this answer?  
> **username_8**: @username_0  Tried with `docker build --dns 8.8.8.8 -t choco .` did not work. Then I added `"dns": ["8.8.8.8"]` in daemon.json did not work.  
> **username_0**: I thought the dns flag was at run not at build?  

---

### Answer by username_4 on 2019-12-16. Score: 5

At a command prompt run ipconfig /all and look for a DNS Servers line in the output with something that looks like an IPv4 address. That's your host machine's DNS server(s).
Edit C:\ProgramData\Docker\config\daemon.json and add a dns entry with that IPv4 address. For example, if your DNS Server is 192.10.0.2 and 8.8.8.8 is Google's DNS as a backup:
{
    "dns": ["192.10.0.2", "8.8.8.8"]
}

Now restart Docker Desktop and the remote URLs can be resolved by Docker, either at build or runtime.
This solution came from Faithful Anere at https://medium.com/@faithfulanere/solved-docker-build-could-not-resolve-archive-ubuntu-com-apt-get-fails-to-install-anything-9ea4dfdcdcf2
UPDATE 2024
You now need to open Docker Desktop and go to Settings > Docker Engine to update this setting. If you edit the file directly it gets overwritten when you restart Docker.
UPDATE 2, 2024
You can edit the file at %userprofile%\.docker\daemon.json and then restart Docker. Using Docker Desktop to modify the file may lose your changes when Docker Desktop is restarted.


---

### Answer by username_0 on 2017-09-27. Score: 2

As comments are transient, here's some info for the next person trying to solve this problem. Please feel free to edit this answer to provide more details, unless you're a Docker for Windows pro, in which case please give a better answer :D

I went to demo the problem for my IT group after having changed my NIC on my VM to bridged and adding my thunderbolt adapter. As there are security systems in place, I realized I needed to add the security software to my VM, but as it isn't joined to the domain, that was a problem. Switching it back to NAT on the wifi adapter, and then going to demo the problem in my Windows 2016 VM somehow magically made it start working.

Same network. Same VM configuration. Same software and host, no changes to anything I can track.

Having checked Get-ContainerNetwork or Get-WinNat showing nothing, I really had been at my end of diagnostics. Changing that NIC adapter and then changing it back apparently caused something to reset. Good times.

So, I don't have a solid answer, but I have a good workaround for the next person stuck in my shoes, which, given my track record of StackExchange questions and answers, will be me. But I hope it helps you out too, random internet asker.

---

And an XKCD tax, for those impossible to solve problems.

[![XKCD Comic Link to ](https://i.sstatic.net/ZAhuo.png)](https://xkcd.com/979/)

> **Comments:**
> **username_3**: According to this description, I'm tempted to put a bill on a DNS cache cleared by the shut/no shut of the network stack as Windows have this kind idea to cache negative request also. If it comes to happen again,  may worth trying a `ipconfig /flushdns` on the windows host  
> **username_0**: Meant to add, the host in this case is OSX, if you mean the base OS hosting everything. If you mean where I'm running the docker container, that's windows.  
> **username_3**: I mean the windows host, I don't remember *nix based   network stacks caching negative queries  

---

### Answer by username_5 on 2021-04-28. Score: 1

I recently had this frustrating problem but I managed to fix it today.

What I did, is in the desktop app on Windows / Mac you can edit the Daemon file. Under Settings in the Docker App under Docker Engine, I added the line at the bottom of the file just above the last curly brace. `"dns": [ "192.168.4.100", "8.8.8.8" ]`

This then allows the Docker Containers all that you now build to use your host's DNS server. Technically if you can access: <https://chocolatey.org/install.ps1> then you should be able to access the choco repository.

I have also built the image in <https://github.com/jasric89/vsts-agent-docker/tree/master/windows/servercore/10.0.14393> and labeled it in the repo:

microsoft/windowsservercore:10.0.14393.1358

I then set: `RUN choco feature enable --name allowGlobalConfirmation` before my first Choco Install command, this enables choco to install all the files and not error.

With all that set my Docker File Ran and built the image. Well in my Test Env now testing in my prod env. :)

Links that helped me:

<https://github.com/moby/moby/issues/24928>
<https://github.com/jasric89/vsts-agent-docker/blob/master/windows/servercore/10.0.14393/standard/VS2017/Dockerfile>
<https://docs.chocolatey.org/en-us/troubleshooting>
<https://github.com/moby/moby/issues/25537>


---

### Answer by username_6 on 2018-06-10. Score: -1

Try installation instructions from https://chocolatey.org/install#completely-offline-install (section "Installing behind a proxy"):
    @powershell -NoProfile -ExecutionPolicy Bypass -Command "[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

> **Comments:**
> **username_3**: You're answering a different question here, the question is why the container can't resolve internet addresses  

---

