Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
DNS not working in a service with an overlay network. It is seemingly dependent on the creation order of unrelated networks. #28188
Steps to reproduce the issue:
The above service was chosen as it was concise, but I could run the same test with an 'alpine sleep', exec in, and clearly see that Internet access was ok, but hosts would not resolve.
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Additional environment details (AWS, VirtualBox, physical, etc.):
I have docker-machine version 0.8.2, build e18a919
I hit the issue also in AWS for Docker Beta 1.12.3, where it was prevalent, but more inconsistent.
What's the error from
Yep, the host-machine, if I ssh into it, the DNS works fine. I can nslookup www.google.com, and get what I would expect. For the record that is ...
The result of nslookup in a failing container is ...
The containers that work, return the following....
To reply tot his, I span up a new docker-machine for the test, since I've been working with 1.13. So I can confirm that the issue persists in 1.12.4rc1. I was using a 1.13rc3 client, fwiw (the script needs to be slightly altered, since it returns the task information differently)
I also ran it in 1.13 rc3, and I get the same issue. I note, I initially did not get the same issue, when I ran with a host which already had a bunch of things running. On a fresh machine, the issue returned.
Here are the gory details on what exactly is casing the problem with the default configs..
When you create overlay networks the default subnet is a /24 network from 10.0.0.0. Since you have three networks the subnets will be..
The VM created by docker-machine with vbox driver will get the following resolv.conf file
If you create a service on network 2 its IP on the overlay network will be 10.0.1.3. To reach the external DNS server 10.0.2.3 packet will be route via container's
If you create a service on network 3, the task IP will be 10.0.2.3. Since the external DNS server is also on the same subnet, in fact its the same IP here, packet will not get routed correctly and the resolution will fail.
The 2nd network had the