Domain names inside private network not resolving through vpn

[bspates]

Expected behavior

Docker for mac should resolve through VPN connection

Actual behavior

Docker seems oblivious to currently open VPN connection

Information

Diagnostic ID: BBD3F7BF-C35D-4FB9-AB04-80ADBD8DBB9B
Docker for Mac: 1.12.0-beta21 (Build 10868)
macOS: Version 10.11.6 (Build 15G31)
[OK] docker-cli
[OK] app
[OK] moby-syslog
[OK] disk
[OK] virtualization
[OK] system
[OK] menubar
[OK] osxfs
[OK] db
[OK] slirp
[OK] moby-console
[OK] logs
[OK] vmnetd
[OK] env
[OK] moby
[OK] driver.amd64-linux

Steps to reproduce

1. Turn on docker for mac
2. Connect to vpn (I have tried reversing these first two steps)
3. Attempt to build image that requires resolution to domain inside of VPN

Example docker file:

FROM node:argon

RUN mkdir /srv/app
WORKDIR /srv/app
RUN npm set registry <internal vpn domain>
RUN npm install -g -q coffee-script grunt-cli

ADD . /srv/app
RUN npm install -q

RUN grunt
EXPOSE 3000

CMD ["npm", "start"]

[djs55]

Thanks for the report and uploading the diagnostic logs. Could you paste the contents of /etc/resolv.conf and scutil --dns? Unfortunately these aren't in the current diagnostics upload but are really useful for figuring out DNS problems. If you'd rather not post those on public bug tracker could you tell me whether there are resolvers in one but not the other?

My theory is that your VPN software has updated the Mac system configuration database with new resolvers so new IPs should be visible in scutil --dns but it has not updated the legacy /etc/resolv.conf file. There is a warning in /etc/resolv.conf saying it is not used any more by "most processes". Unfortunately D4M currently uses it, although we're investigating switching to the equivalent of scutil --dns instead.

[bspates]

@djs55
I don't feel comfortable pasting the contents of that file,

BUT it does look like resolv.conf is not getting its search domain updated once I've connected to the VPN, while scutil -dns is.

Is that suppose to be updated dynamically in resolv.conf?

[BirgerK]

+1

I often got DNS-problems because I use docker-registries which are only known on private DNS-servers. Then I have to manually edit my resolv.conf....

It would be useful if docker would use the dns which osx is using. Is there a special reason why docker is not already behaving like this?

[ringods]

Another use case besides VPN is a company network that forces to use the local DNS and doesn't allow direct access to Google or other public DNS. My containers still have Google DNS in resolv.conf, but the local DNS servers are 10.x.x.x. addresses. Once I update the resolv.conf of my containers to the local DNS, everything works flawlessly.

[myw]

In my company's setup, my host laptop gets a company-wide search domain added to /etc/resolv.conf (not actually, but OSX mimics that behavior anyway, so it shows up there) whenever it acquires a DHCP address, which is the "right way" to add search domains.

In the Moby linux internals, it seems that the VM's dhcp client, udhcpc has this capability as well. It automatically rewrites /etc/resolv.conf when it acquires a DHCP IP. However, the "dhcp server" it's connecting to (slirp?) does not transfer search domains from the host machine. So far, my solution has been to [hack!] edit the initrd to add a config file /etc/udhcpc/udhcpc.conf that turns off the "Automatically rewrite resolv.conf on DHCP lease" feature, and hard-code an /etc/resolv.conf that works with the mock DHCP server that VMKit spins up.

I'm pretty sure the issue lies in slirp and can be fixed by adding the host machine's search domains to the responses it gives DHCP clients. This should be fairly doable: ocaml-dns already includes solid functionality for parsing search domains out of the resolv.conf, and there's already resolv.conf parsing code in https://github.com/docker/vpnkit/blob/master/src/com.docker.slirp/src/resolv_conf.ml

[BirgerK]

I did yesterday an update to the current beta-version. In the release-notes was a notice for this issue.

Seems they're now using the system-dns-network-settings-stuff. On my mac-docker it's working now. Can you confirm it?

[bspates]

Looks like this is still an issue for me. The image being built is still not using the vpn search domains.

[myw]

Still an issue for me as well, despite my great excitement that it might be fixed after seeing the release notes. However, I have come up with a much less hacky set of initrd changes that generically fix the problem. Patch to the initrd is attached, along with a patched initrd.img from the Beta-22 release. Just replace yours with mine, or, if you don't trust me that blindly, unpack yours, apply the patch, and repack (see some instructions if you need help).

initrd.patch
initrd.img

The idea is the following: the VM has access to the host's resolv.conf (via the standard /private/etc mount), so on DNS renew and bind, after the VM's resolv.conf is rewritten by the udhcpc script, find all the search domains from the host resolv.conf, and append them to the VM's resolv.conf uniquely (i.e. never append a domain that already exists).

This only works after the host filesystems have been mounted with FUSE, however, which is why the changes to the networking service init.d script to start it after FUSE is up.

[myw]

@djs55 is there any kind of milestone/expected progress for this issue?

[djs55]

Unfortunately this won't be fixed in the next beta (due today), but I am investigating. I made an initial attempt to extend the DHCP offer with the search domain option, but somewhere in the chain the setting was dropped. I then realised that DHCP isn't a great place to put this information because we'd like the setting to update immediately when the Mac setting changes and a DHCP offer has a non-negligible associated lease time. Therefore I'm now investigating adding an /etc/resolv.conf override to the configuration database shared with the VM. I'll keep you posted, and sorry it's not been fixed yet.

[gcarre]

@djs55 I have the issue too, and the cisco vpn client we use doesn't update /etc/resolv.conf
I'll be happy to share my configuration with you if you want, hit me up at guillaume.carre at ticketfly.com
I would also be happy to meet with someone at the SF Docker office if it can help, my office is just across the street :).

[djs55]

Quick update on this issue:

• as of beta22 the DNS servers are read from the System Configuration database, rather than /etc/resolv.conf. So hopefully if a server is listed in scutils --dns it should be usable by Docker.
• as of the (unreleased, but due this week) beta25, search domains are being sent through to the VM
• also as of the (unreleased, but due this week) beta25, entries in /etc/hosts on the Mac should be resolvable too

I'll ping the issue again when beta25 is out and available for testing. Thanks for all your patience (and offers of help) so far!

[djs55]

OK, beta 25 has been released! The only thing to watch out for is the search domains, while they are persistent, they aren't updated dynamically. In beta 25 it's necessary to restart the app for them to take effect. We'll hopefully fix that in future -- there was a patch to do it live but it caused some regressions and had to be reverted. Let me know if it works for you! Feel free to open a fresh issue if something goes wrong.

[thehesiod]

this is not working with beta25 even after restarting docker for mac

[velimir]

I have the similar issue. Containers can't resolve internal names.
Name resolvers are visible from scutil --dns, but /etc/resolv.conf doesn't have them.

$ docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 17:32:24 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 17:32:24 2016
 OS/Arch:      linux/amd64
 Experimental: true

[bspates]

@djs55 This is still an issue for me in the original scenario described in this ticket.

[velimir]

hey @djs55 can you please clarify why this issue has "fixed" state? This is still an issue at least for me. I there a workaround, which I missed?

[jazzfog]

I have same issue (Beta 42) - When I connect to VPN - containers can not resolve internal hosts.
Meanwhile if I run docker within ViertualBox machine provisioned by Vagrant - everything works as expected.

[GeoffreyBooth]

I’m still seeing this issue as well, in 17.03.1-ce-mac5 (16048).

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked