-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
the --dns option is not working with windows container #397
Comments
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. |
@panmanphil can you reopen this in https://github.com/docker/docker/issues/new and ping @msabansal ? |
Will do |
@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 |
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? |
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. |
@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. |
It is not getting resolved, yes perhaps a network trace would help confirm this. But consider this. On the host docker run -it -- --dns mydnsserver microsoft/windowsservercore cmd Other than not delegating what else could this be? there is only the nat network. I can ping the dns server by ip address |
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. |
I am running into this issue as well. ` Pinging google.com [172.217.7.174] with 32 bytes of data: *** UnKnown can't find google.com: Server failed Non-authoritative answer: PS C:> |
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? |
Can you please elaborate the issue you are having? What hacking around are you talking about? |
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: Ideally, the daemon should forward DNS requests but this is not happening. |
@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. |
Here is an ipconfig /all from a microsoft/windowsservercore container: IPv4 Address. . . . . . . . . . . : 172.22.219.188(Preferred) 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 *** 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. |
If I specify, --dns=8.8.8.8 this shows up on the container which is good: DNS Servers . . . . . . . . . . . : 172.22.208.1 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. |
@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. |
@krushmike Primary fails properly and in accordance to the DNS RFC spec but nslookup doesn't support delegation |
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. |
@krushmike Can you point me to some example on how your application uses DNS. Perhaps a reference to the API call your app uses? |
We have various connection strings which point to DNS names. For instance, IIS connecting to a backend database or some other service. |
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 |
@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. |
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. |
@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. |
@msabansal, were you able to reproduce? Hopefully you have identified the issue or can offer a potential workaround. Looking forward to an update. |
@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. |
@krushmike I've also been using |
@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}"'; Again, not ideal but it works :-) |
Late reply, but thank you @krushmike. That is very helpful. |
Is using |
Any update? |
@panmanphil Did you reopen this in somewhere at https://github.com/docker/docker/issues ? |
there is no solution after 3 years? |
@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. |
Closed issues are locked after 30 days of inactivity. 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. |
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
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
The text was updated successfully, but these errors were encountered: