Hello Daniel, Thank you so much for the detailed response, much appreciate it. > On Thursday, 15 January 2015 7:47 PM, Daniel P. Berrange wrote: > NB this won't just be a Docker problem. It has the potential to affect any > container technology. eg a simple libvirt LXC container can be setup sharing > the filesystem namespace, but with separate network namespace and so no longer > have access to the same 127.0.0.1:53 binding. And libvirt-sandbox can setup > KVM guests where the guest runs off a readonly passthrough of the host's / > but obviously the KVM guest will not see any host network interface. Right, I can imagine. > I think that probably the solution will have to involve any such apps doing > a bind mount on /etc/resolv.conf to reply the file with alternative content > Historically they tried to avoid that because doing a bind mount onto > /etc/resolv.conf would prevent the host OS from unlinking/replacing that > file. With this dnssec change though, /etc/resolv.conf will never get its > content changed once the OS is booted, so this bind mount problem would > no longer be an issue. > > An alternative would be for the container technology to setup some kind > of port forward, so that 127.0.0.1:53 inside the container get magically > forwarded to 127.0.0.1:53 outside the container. I think the above two options seem more suitable, rather inviting. I've heard the second one before, about using iptables(8) rules for facilitating such access. There was also talk of having a dedicated network interface. > A slightly off the wall idea would be for the resolv.conf to not mention > 127.0.0.1:53 at all, and instead listen for DNS requests on a UNIX socket > in the filesystem. eg have resolv.conf refer to > "/var/run/resolv.sock". > A container starting a new network namespace, but sharing the mount > namespace could still access that UNIX socket. If they had a private > mount namespace, they could bind mount the UNIX socket in. The big problem > is that while you could probably update glibc easily enough, there are > probably a fair few apps that directly parse /etc/resolv.conf and would > almost certainly get confused by a UNIX domain socket. So this idea would > probably not fly. > > Unless perhaps glibc could just try /var/run/resolv.sock unconditionally > and only if that's missing, then fallback to /etc/resolv.conf which would > contain 127.0.0.1:53 still. That way most apps would jsut work with the > UNIX socket and resolv.conf would still have a TCP socket for those which > need it. These two appear rather intrusive. Besides changing glibc behaviour is a very long shot. :) > All the solutions need some work - I can't see any obvious way of making > the containers problem you describe "just work" without the developers > of such software doing some work. I see, that is tricky. I'll try and get in touch with these container developers, let's see how it goes. If I'm not very far off, Docker, Rocket, libvirt LXC are the major players in this space? Ie. it'd suffice to reach out to them? Am I missing someone? (/me also makes a note about further investigating first two options.) Thank you. --- Regards -Prasad http://feedmug.com _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
