Revert internal resolver for default bridge#48020
Conversation
robmry
added
kind/bug
This reverts commit d365702. Because buildkit doesn't run an internal resolver, and it bases its /etc/resolv.conf on the host's ... when buildkit is run in a container that has 'nameserver 127.0.0.11', its build containers will use Google's DNS servers as a fallback (unless the build container uses host networking). Before, when the 127.0.0.11 resolver was not used for the default network, the buildkit container would have inherited a site-local nameserver. So, the build containers it created would also have inherited that DNS server - and they'd be able to resolve site-local hostnames. By replacing the site-local nameserver with Google's, we broke access to local DNS and its hostnames. Signed-off-by: Rob Murray <[email protected]>
This reverts commit 18f4f77. Because buildkit doesn't run an internal resolver, and it bases its /etc/resolv.conf on the host's ... when buildkit is run in a container that has 'nameserver 127.0.0.11', its build containers will use Google's DNS servers as a fallback (unless the build container uses host networking). Before, when the 127.0.0.11 resolver was not used for the default network, the buildkit container would have inherited a site-local nameserver. So, the build containers it created would also have inherited that DNS server - and they'd be able to resolve site-local hostnames. By replacing the site-local nameserver with Google's, we broke access to local DNS and its hostnames. Signed-off-by: Rob Murray <[email protected]>
robmry
force-pushed
the
revert_internal_resolver_for_default_bridge
branch
from
0864768 to
74d77d8
Compare
Buildkit is replacing the site-local DNS server with Google's, not us. If that's the only root cause, why can't it be fixed in Buildkit by having Buildkit stop shooting itself in the foot? |
I think it could be ... if our understanding of the reported issue is right, and we haven't missed anything else. As 27.0 will ship tomorrow, the sensible option is reverting - to give ourselves some thinking time, and to deal with buildkit's DNS properly (hopefully getting rid of the Google fallback once and for all). |
|
According to moby/buildkit#4524 (comment) there is no bug. Buildkit is behaving as intended, apparently: when the network mode for the build is unspecified, containers are only guaranteed to have public internet access. |
|
It also sounds like there is a viable workaround of projecting |
corhere
left a comment
corhere
left a comment
There was a problem hiding this comment.
Blocking for more discussion. I want to hear from @tonistiigi
|
@corhere The issue is not (only) related to running buildkit container with host networking. If extra mounts should be added to container when the user specifies The main case seems to be that all current buildkit releases make a distinction if |
robmry
added
kind/bugfix
4 participants
- What I did
Because buildkit doesn't run an internal resolver, and it bases its /etc/resolv.conf on the host's ... when buildkit is run in a container that has 'nameserver 127.0.0.11', its build containers will use Google's DNS servers as a fallback (unless the build container uses host networking).
Before, when the 127.0.0.11 resolver was not used for the default network, the buildkit container would have inherited a site-local nameserver. So, the build containers it created would also have inherited that DNS server - and they'd be able to resolve site-local hostnames.
By replacing the site-local nameserver with Google's, we broke access to local DNS and its hostnames.
Note that buildkit's build containers currently use host networking, although that may change. But, until it does, the only problem is that (without
--network=host) buildkit replaces localhost resolvers with the Google defaults. If it didn't do that, and kept127.0.0.11, it'd work as expected.- How I did it
- How to verify it
- Description for the changelog
n/a - but check the notes for https://github.com/moby/moby/pull/47602 have been removed