the --dns option is not working with windows container

[panmanphil]

Expected behavior

calling docker run with the --dns should use that server as the sole, or at least as the first dns server in the list

Actual behavior

The default gateway is listed as the first dns server in the list on my vm ware hosted windows 10 instance. On a windows 2016 instance, the hosts dns server is listed first.

Information

Windows 2016 version:
PS C:\Windows\system32> docker version
Client:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

Server:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

Windows 10 version:
PS C:\Windows\system32> docker version
Client:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

Server:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

Steps to reproduce the behavior

1. docker run --it --rm --dns 8.8.8.8 microsoft/windowsservercore powershell
2. nslookup
3. observe the dns server ip address does not match the server passed with --dns
4. ipconfig /all to see all the dns servers in the container

PS C:> ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : a40f78e2ee08
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : localdomain

Ethernet adapter vEthernet (Container NIC d5dcaef9):

Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
Physical Address. . . . . . . . . : 00-15-5D-2C-09-69
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::d1d2:9df9:c877:7721%18(Preferred)
IPv4 Address. . . . . . . . . . . : 172.17.60.44(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.17.48.1
DNS Servers . . . . . . . . . . . : 172.17.48.1
8.8.8.8
NetBIOS over Tcpip. . . . . . . . : Disabled

[simonferquel]

Thanks for the report. @friism Can we have someone from Windows Containers team look at it ? (we don't do anything related to dns in D4D.

[friism]

@panmanphil can you reopen this in https://github.com/docker/docker/issues/new and ping @msabansal ?

[panmanphil]

Will do

[msabansal]

@panmanphil This is by design. We have this because we want to enable service discovery. 172.17.48.1 is the server address of dns server running in docker which intercepts container name queries and allow service name resolution

[panmanphil]

That would be fine, and needed for swarm, I understand that. But, if it doesn't delegate to other dns servers the queries it doesn't directly control, how can --dns accomplish anything?

In this case the scenario is aws ecs with a vpc + vpn to an internal datacenter. We need to be able to resolve names in that datacenter, and have a dns server to do so. Even if that dns server was route53, we'd want to pass in dns server names. Is there another way to accomplish this?

[msabansal]

It does delegate to other servers. The first request always goes to the docker dns server which replies back with a SRV_FAIL response in case name doesn't match a service/container. DNS client in windows then delegates and continues resolving the query using other dns servers in the list.

[msabansal]

@panmanphil I believe you should not have any issues with the scenario you are talking about. If you are seeing an issue perhaps you can take a network trace on the host and see if the query is not going to the DNS servers you mentioned.

[panmanphil]

It is not getting resolved, yes perhaps a network trace would help confirm this. But consider this.

On the host
nslookup
server mydnsserver
myserver.example.com (works )

docker run -it -- --dns mydnsserver microsoft/windowsservercore cmd
in the container
nslookup myserver.example.com (does not work)

Other than not delegating what else could this be? there is only the nat network. I can ping the dns server by ip address

[msabansal]

Not sure about the issue. This should have worked. Perhaps there is some issue with network routing.  you can do nslookup - mydnsserver and see if there is an issue. Nslookup doesn't delegate so I think that is an issue.

[darkshade9]

I am running into this issue as well.

`
PS C:> ping google.com

Pinging google.com [172.217.7.174] with 32 bytes of data:
Control-C
PS C:> nslookup google.com
Server: UnKnown
Address: 172.24.32.1

*** UnKnown can't find google.com: Server failed
PS C:> nslookup google.com 4.2.2.2
Server: b.resolvers.Level3.net
Address: 4.2.2.2

Non-authoritative answer:
Name: google.com
Addresses: 2607:f8b0:4004:80d::200e
216.58.218.238
216.58.218.238
216.58.218.238

PS C:>
`

[roadbikemike]

I am having this same issue which really causes inconvenience and "hacking" in order to get around. Any idea when a fix may be issued?

[msabansal]

Can you please elaborate the issue you are having? What hacking around are you talking about?

[roadbikemike]

When we start a Windows container, DNS is set to the docker interface on the Windows host within the docker virtual network. As a result, DNS cannot resolve anything externally and no forwarding occurs. When using the --dns option, this does nothing. Same with the docker daemon parameters. As a result, we have to launch the docker instance with a scheduled task to run at boot which sets the primary/secondary DNS servers in the container (aka hack) via PowerShell. When this is done, we can resolve names as expected. There is lots of information on the issue here as well:

moby/moby#30260

Ideally, the daemon should forward DNS requests but this is not happening.

[msabansal]

@krushmike The issue mentioned in the other thread was because of DNS search list not being supported. We have that support now. Every time I debug an issue where DNS isn't working it ends up being some other issue.

Can you please check what information "ipconfig /all" shows. And if nslookup works in the container? The dns server is the server of your choice.

[roadbikemike]

Here is an ipconfig /all from a microsoft/windowsservercore container:

IPv4 Address. . . . . . . . . . . : 172.22.219.188(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.22.208.1
DNS Servers . . . . . . . . . . . : 172.22.208.1
10.6.0.10
10.6.0.11

Here is what is interesting. Doing a ping to google.com yields:

Pinging google.com [172.217.6.14] with 32 bytes of data

However, doing an nslookup on google.com yields:

PS C:> nslookup google.com
Server: UnKnown
Address: 172.22.208.1

*** UnKnown can't find google.com: Server failed

When our services try to connect to a dependency, they are using whatever nslookup uses to resolve the name. Therefore, they cannot connect. That is the root of the issue.

[roadbikemike]

If I specify, --dns=8.8.8.8 this shows up on the container which is good:

DNS Servers . . . . . . . . . . . : 172.22.208.1
8.8.8.8

However, the container still cannot resolve the name. It is almost like the primary is not fully failing for the request to utilize the secondary.

[msabansal]

@krushmike Nslookup is a utility that doesn't do any delegation :(. We can add support for an inbuilt server that does delegation (like docker does for Linux) but that is a lot of engineering work to solve it for hyperv containers and we choose this approach instead.
Can you update your tooling to use Resolve-DNSName powershell commandlet instead?

[msabansal]

@krushmike Primary fails properly and in accordance to the DNS RFC spec but nslookup doesn't support delegation

[roadbikemike]

Resolve-DNSName does indeed resolved properly. However, our applications are using DNS names to connect to resources and this is not working. So, something is still amiss with DNS on Windows containers :-(. When we set primary and secondary to our DNS servers, everything works fine but again, this is a hack and not ideal.

[msabansal]

@krushmike Can you point me to some example on how your application uses DNS. Perhaps a reference to the API call your app uses?

[roadbikemike]

We have various connection strings which point to DNS names. For instance, IIS connecting to a backend database or some other service.
If we could override the DNS settings (both primary and secondary) in the container via a switch during docker run, this would fix the issue. Question is, why does the primary not fully fail and send the request to the secondary as specified via --dns=8.8.8.8

[roadbikemike]

If I run the following from the container to set the primary/secondary DNS addresses once running, everything works as expected:

Set-DnsClientServerAddress -InterfaceAlias vEthernet* -ServerAddresses PRIMARY_DNS, SECONDARY_DNS

[msabansal]

@krushmike The only reason I can think of is because os something not honoring delegation. do you have a dockerfile example of something I can try and debug? It would be really helpful. We have various tests that cover these scenarios and everything works fine.

[roadbikemike]

You can reproduce this by bringing up a microsoft/windowsservercore container:

docker run -it microsoft/windowsservercore powershell

Once the powershell command comes up, type "nslookup google.com". You will notice this fails. Whatever nslookup uses under the covers to resolve DNS is the same process our .NET applications use to resolve dependencies (and fail). From inside the container, run:

Set-DnsClientServerAddress -InterfaceAlias vEthernet* -ServerAddresses PRIMARY_DNS, SECONDARY_DNS

Confirm by "ipconfig /all". If you see your primary and secondary servers in the DNS setttings, try nslookup to google.com again. It should succeed.

In this test case, we are not using a dockerfile. Simply bringing up a vanilla server core image.

[roadbikemike]

@msabansal, did you by any chance have a moment to reproduce this issue? Please let me know if there is anything I can do to assist or get this moving forward.

[roadbikemike]

@msabansal, were you able to reproduce? Hopefully you have identified the issue or can offer a potential workaround. Looking forward to an update.

[msabansal]

@krushmike Yes. Thank you. This is a known issue which will happen with a non delegating resolver. The solution we have currently implemented is the best solution given our timelines. I would see if we can do something about this in our next milestone.

[fusionx86]

@krushmike I've also been using Set-DnsClientServerAddress to get around this problem, but the most annoying thing is that the DNS setting doesn't persist across the intermediate containers/layers during a build or in a new container created from an image where the DNS server was previously set. Are you aware of a way to make it persist? This is a vexing problem.

[roadbikemike]

@fusionx86 The only way we were able to get around this issue is to set a scheduled task which executes on start and runs Set-DnsClientServerAddress.

$action = New-ScheduledTaskAction -Execute 'Powershell.exe'-Argument '-NoProfile -WindowStyle Hidden -command "& {Set-DnsClientServerAddress -InterfaceAlias vEthernet* -ServerAddresses ADDRESS1, ADDRESS2}"';
$trigger = New-ScheduledTaskTrigger -AtStartup;
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "FixLocalDNS" -Description "Changes local DNS settings to address issue in Docker" -RunLevel Highest -User System;

Again, not ideal but it works :-)

[fusionx86]

Late reply, but thank you @krushmike. That is very helpful.

[midacts]

Is using Set-DnsClientServerAddress after the deploy still the best option available today?

[danieldaeschle]

Any update?

[doggy8088]

@panmanphil Did you reopen this in somewhere at https://github.com/docker/docker/issues ?

[Raschmann]

there is no solution after 3 years?

[mat007]

@Raschmann this does not look like an issue with the Docker Desktop application itself but with the upstream docker windows container implementation. The appropriate place to open an issue would be https://github.com/moby/moby.

[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