Domain names inside private network not resolving through vpn about for-mac HOT 20 CLOSED

+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?

from for-mac.

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.

from for-mac.

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!

from for-mac.

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

from for-mac.

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

from for-mac.

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

from for-mac.

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.

from for-mac.

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.

from for-mac.

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.

from for-mac.

@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?

from for-mac.

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

from for-mac.

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?

from for-mac.

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

from for-mac.

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.

from for-mac.

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

from for-mac.

@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 :).

from for-mac.

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?

from for-mac.

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.

from for-mac.

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

from for-mac.

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

from for-mac.