Cannot connect to chocolatey.org or any other internet site from within container

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

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.

StackExchange DevOps Q#2155, answer score: 6