Warn when no external DNS nameservers are found#49827
Conversation
Since commit 925b484 ("No fallback nameservers for internal resolver"), if the host's resolv.conf has no nameservers and no servers are supplied via config, the internal resolver will not use Google's DNS - so the container will not be able to resolve external DNS requests. That can happen when container's are "restart-always" and the docker daemon starts before the host's DNS is configured. So, to highlight the issue (which may not be an error, but probably is), include a warning in the container's resolv.conf file. Also, log a warning - logs currently say "No non-localhost DNS nameservers are left in resolv.conf. Using default external servers". But, that's misleading because it's from an initial resolv.conf setup, before the internal resolver configured without those fallbacks - we'll drop the fallbacks completely once the default bridge has an internal resolver). Signed-off-by: Rob Murray <rob.murray@docker.com>
|
@robmry quick question (could be for a follow-up); would we be able to log a warning when loading the config? I'm considering I should also dust-off my PR that prints the external resolvers in |
In normal running, a network-connected Linux host with no external resolvers would be very unusual - it wouldn't be able to resolve DNS requests, so I don't think it would be surprising that its containers wouldn't resolve DNS either (at least, without a That's why the original change didn't worry about that case too much ... but the issue that's been raised seems to be caused by dockerd starting before the host's DNS is configured, and containers that start immediately because they're configured with a "restart" option. So, by the time Without containers starting early, no DNS when the daemon starts isn't an issue. If the containers do start early, there will now be warnings in the logs - so I don't think it's worth adding extra warnings during startup either.
That could be useful sometimes - but perhaps also misleading, because containers only snapshot the server's state when they start and the daemon-level DNS related options can be overridden per-container. Since you worked on that PR, I think we've dealt with the issues around localhost nameservers - mostly by making DNS lookups from the host's netns when a nameserver address is learnt from the host. (The default bridge network still uses Google's fallback servers in that case but, hopefully, we'll be able to hook it up to the internal resolver again soon - just need to sort out the buildkit issue.) So, DNS config is per-container not per-daemon - and the config is now visible in comments in the container's |
- What I did
Since commit 925b484 ("No fallback nameservers for internal resolver"), if the host's resolv.conf has no nameservers and no servers are supplied via config, the internal resolver will not use Google's DNS - so the container will not be able to resolve external DNS requests.
That can happen when containers are "restart always/unless-stopped" and the docker daemon starts before the host's DNS is configured.
So, highlight the issue (which may not be an error, but probably is).
- How I did it
Include a warning in the container's resolv.conf file.
Also, log a warning - logs currently say "No non-localhost DNS nameservers are left in resolv.conf. Using default external servers". But, that's misleading because it's from an initial resolv.conf setup, before the internal resolver configured without those fallbacks - we'll drop the fallbacks completely once the default bridge has an internal resolver).
- How to verify it
Updated unit test.
With an empty
/etc/resolv.confon the host ...- Human readable description for the release notes