Docker Community Forums

Share and learn in the Docker community.

Docker pull not using correct DNS server when private registry on VPN

I’m getting the same problems simply trying to use Docker4Mac on my company network and trying to access our company registry. My mac’s nameservers are correctly set to 192.168.0.47 and 192.168.0.48 but if I ‘screen’ into the docker alpine linux vm the /etc/resolv.conf file contains only the google nameservers. As a result, pulls from the internal registry fail.

From what other people have said, is the Docker4Mac designed to pick up the nameserver config from the host Mac and replicate it in the VM?

One thing I did note that might have an impact is that I’m using a MacBook Air with an ethernet adaptor which means en0 is the wifi card (which is off) and my normal network connection is on en3.

My network setup is ‘nat’ and native/port-forwarding is true. Using hostnet for my network setup caused Docker4Mac to fail to start (maybe related to the en0 / en3 stuff)

Here is my OS X /etc/resolv.conf and scutil --dns (company name obfuscated):

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
search eng.mycompany.com
nameserver 172.31.18.70
nameserver 172.31.27.35
nameserver 172.31.47.153

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : eng.mycompany.com
  nameserver[0] : 172.31.18.70
  nameserver[1] : 172.31.27.35
  nameserver[2] : 172.31.47.153
  flags    : Request A records
Reachable

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : eng.mycompany.com
  nameserver[0] : 172.31.18.70
  nameserver[1] : 172.31.27.35
  nameserver[2] : 172.31.47.153
  if_index : 4 (en0)
  flags    : Scoped, Request A records
Reachable

Here is Alpine Docker’s /etc/resolv.conf after restarting Docker after logging into our VPN:

moby:~# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

This seems broken to me. Could you not somehow leverage OSX’s name resolution? Proxy requests through to that? Otherwise…I forsee further acrobatics. If I want custom settings, I have to console into the VM and modify /etc/hosts, each time the system is restarted? It’s my local box…I’m not looking for DNS resolution, I’m looking for local name resolution.

Something seems iffy with how docker is resolving hostnames. In the example below, while the OS can resolve registry.blah.com, it looks like docker-engine can’t. If I change the hosts entry to just “registry” it works just fine.

moby:~# grep registry /etc/hosts
127.0.0.1       localhost registry.blah.com
moby:~# docker tag 8b162eee2794 registry.blah.com:5000/registry
moby:~# docker push registry.blah.com:5000/registry
The push refers to a repository [registry.blah.com:5000/registry]
Get https://registry.blah.com:5000/v1/_ping: dial tcp: lookup registry.blah.com on 192.168.65.1:53: no such host
moby:~# ping -c 1 registry.blah.com
PING registry.blah.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.101 ms

--- registry.blah.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.101/0.101/0.101 ms
2 Likes

Hi Dave, where can we go to see updates on defect #3124?

As far as I know, the bug tracker is not public so you won’t be able to follow on updates. However, if the issue is fixed you should see the issue number in the release notes.

I am facing the same problem with Version 1.11.1-beta14 (build: 8670). When I hop on VPN i get this

➜ ~ docker pull redis Using default tag: latest Pulling repository docker.io/library/redis Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/redis/images. You may want to check your internet connection or if you are behind a proxy.

Fingers crossed #3124 gets into the next release candidate, this causes me real pain when working from home

Facing the same issue with Docker version 1.12.0-rc2, build 906eacd, experimental, encountered via https://forums.docker.com/t/docker-pull-timeout/15015:

$ docker pull hello-world

Using default tag: latest
Pulling repository docker.io/library/hello-world
Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy.

$ cat /etc/resolv.conf

search intra.company.io
nameserver 10.9.69.70
nameserver 8.8.8.8

$ scutil --dns

DNS configuration

resolver #1
  search domain[0] : intra.company.io
  nameserver[0] : 10.9.69.70
  nameserver[1] : 8.8.8.8
  flags    : Request A records
Reachable

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
Not Reachable
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : intra.company.io
  nameserver[0] : 10.9.69.70
  nameserver[1] : 8.8.8.8
  if_index : 5 (en1)
  flags    : Scoped, Request A records
Reachable

$ screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

$ cat /etc/resolv.conf

search local
nameserver 192.168.65.1

Adding 8.8.8.8 to the VM image’s resolv.conf fixes the issue. I don’t know where 192.168.65.1 is coming from.

I would expect to be able to pull images both from index.docker.io and from docker.intra.company.io, without messing with any details in the VM image. I’d also expect to be able to pull from docker.myhomenetwork.local if I connect to that via VPN.

When using Docker Toolbox, its possible to configure the Virtualbox VM to use the host’s resolver. This gets around all of these problems. Any thing the Mac host can resolve, including /etc/hosts entries and domain specific DNS settings in /etc/resolver are automatically picked up, even when changed on the fly.

You do this by stopping the default VM, then the following before starting it again.
VBoxManage modifyvm default --natdnshostresolver1 on

The ability to do something similar would be great. Even better, have it happen automatically since the aim here is to have the xhyve VM as largely transparent. I assume this is something xhyve would need to be able to do.

1 Like

DNS resolution seems to have been fixed. With the current version 1.12.0-rc4-beta20 (build: 10404), I no longer have to apply any workarounds inside the moby VM to push/pull from our internal registry in our VPN.

Nope, doesn’t work for me, I still get an “i/o timeout” trying to login to our internal private registry using the latest “Docker for MAC” Beta - Version 1.12.0-rc4-beta20 (build: 10404) … it still is trying the wrong (external fallback) IP to communicate via https

Not working for me either in 1.12.0-rc4-beta20 (build: 10404)

This is not working for me either. I also tried the suggestions above up updating the resolve.conf within Apline and I still get the error “no route to host” when trying to pull images from my companies internal repository.

and just for reference, still not working in Version 1.12.0-beta21 (build: 11019), and even if I edit host and resolve.conf in the container it doesn’t really work it seems… the login works, but the pull/push e.g. times out

I am still unable to access a private repository on my companies intranet using Version 1.12.1-beta24 (build:11525). I tried using docker run --rm busybox traceroute and this failed to ever find a path from 172.17.0.1.

1 Like

looks like the resolve.conf fix doesn’t work with the latest beta, however adding the relevant host IPs mappings to /etc/hosts seems to work

I have tried both editing my /etc/resolve.conf to add the same entries as the host system and add the ip and name that I am trying to connect with to /etc/hosts without any success. I am still unable to ping the internal docker repository at my company that is on the intranet (172.20.7.x) and not available through the internet.

I have even tried to follow the advice that worked for someone else on this thread https://github.com/docker/docker/issues/25645, but it still didn’t work.

If I docker network inspect 72bd17050252 (bridge network) I get the following:

“IPAM”: {
“Driver”: “default”,
“Options”: null,
“Config”: [
{
“Subnet”: “172.17.0.0/16”,
“Gateway”: “172.17.0.1”
}
]
}

The internal docker registry that I am trying to pull docker images from is on 172.20.7.80. I can seem to get a ping, traceroute, or wget all time out because they can’t connect to the remote host.

Correction:

/etc/hosts workaround is required to pull images from an internal registry, but containers are still not able to resolve internal hosts.

The below workaround was necessary for internal resolution by containers. In our case, we are building our code using maven and maven has to pull from an internal maven repository.

Thanks to the link to https://github.com/docker/docker/issues/25645 by @dwitherspoon, I was able to find another workaround:

cd ~/Library/Containers/com.docker.docker/Data/database/
git reset --hard
cd com.docker.driver.amd64-linux
echo '{ "dns" : [ "1.2.3.4" ] }' > etc/docker/daemon.json
git add etc/docker/daemon.json
git commit -m 'update config' 

1.2.3.4 is the IP address of your internal DNS server. The service restarts automatically.

1 Like

I have found it easier to redirect commands into the tty file like so:
DNS=8.8.8.8 echo "root" >> ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty echo "" >> ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty sleep 1 echo "echo \"nameserver $DNS\" > /etc/resolv.conf" >> ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

You can then use your screen commands to verify the changes, but the above steps are easier to script.