-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nslookup fails inside a container using the default DNS server #216
Comments
Thanks for opening this and providing repro steps. I've confirmed the repro and have opened MSFT internal 38776581 for reference. |
There are a few articles about how Windows nslookup fails if the primary DNS fails, even when the second DNS is working fine: https://defaultroot.com/index.php/2019/10/08/nslookup-default-behaviour-during-failover-of-primary-dns/#:~:text=Windows%20nslookup%20will%20always%20use%20the%20primary%20DNS,in%20the%20nslookup%20command%3A%20So%20all%20is%20well%21 The second article notes that ping is a better basic test of DNS. @doctorpangloss Just so that we can understand severity, is this a blocking issue for you or are you noting an unexpected behavior that is not blocking? Thanks! |
Sounds good if this is a general Windows issue... |
I am reopening this because it seems almost every Windows container user encounters it |
I'm having this issue since the last Windows Update to 10.0.22621.1105. |
does
|
unfortunately not |
It's really hard to say. There's a real issue here. For example would a |
This issue has been open for 30 days with no updates. |
3 similar comments
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
3 similar comments
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
This issue has been open for 30 days with no updates. |
We've the same behaviour in our Kubernetes Environment with Windows Nodes. |
The primary dns server is defaulting to the default gateway, by any chance did you intend to do that? The secondary dns servers will resolve. However a work around that will allow this to work is: docker run -it --rm --net=natgw mcr.microsoft.com/windows/servercore:ltsc2022 You could possibly try deleting the nat network and creating it with the options above as well. Let me know if this works! |
Unfortunately the approach of disabling the default gateway resolves the issue with resolving DNS queries however it breaks the internal docker DNS that resolves the containers ip by the container name. |
Any actual workarounds for this?
Ping 172.17.80.1 => FAIL I tried:
|
Facing the same issue, any updates here? I have no workaround and for me the issue appeared out of nowhere. |
A lot of this is mentioned in bits and pieces above, but here is what's going on, which I confirmed in our lab:
Given the above, our general recommendation is to use the Resolve-DnsName cmdlet instead. Resolve-DnsName uses the built-in DNS client for the OS which will retry with all of the available DNS servers and unlike nslookup also works with configurations that use newer DNS technologies such as DNSSEC, DNS-over-HTTP (DoH) and DNS-over-TLS (DoT). This is the best way to determine if DNS is functioning within the container. Any application that relies on Windows to do the DNS lookup will get the same behavior as Resolve-DNSName. If you really want to use nslookup you can, but be aware of the above limitations. You may also be having DNS connection issues outside of the container host. To narrow that down, use pktmon to trace the packet to see if it leaves the container host in the correct format. In my environment 8.8.8.8 is blocked somewhere on the network. I can confirm it is not an issue with the Windows Container host by doing the following: On the container host:
In the container:
Back on the container host:
In notepad I can look at the Appearance # to find the last appearance of the DNS request packet, check which component it was last seen on, and confirm that the packet looks correct:
Further down in the file I can see that Component 6 is the ethernet adapter:
Whenever the last appearance is the ethernet adapter it's safe to assume the packet left the machine. I verified that the IP addresses are correct, and that the destination MAC address is the physical ethernet switch. Since I never see a response in the pktmon log I know that I never received a reply on the container host. I will leave this issue open for a few days longer, if anyone can show a pktmon log that suggests the container host dropped the packet incorrectly (not including the Moby issue above), I can look into that. If not, I'll close this issue. |
It makes sense to me if there were documentation somewhere that |
@doctorpangloss Thanks for the suggestion, I've submitted a PR to the container networking docs with this information. |
Describe the bug
nslookup
fails inside a container.To Reproduce
Expected behavior
nslookup
should work against the default DNS server.Configuration:
Additional context
The text was updated successfully, but these errors were encountered: