This gets worse when you add an overlay network provider, like flannel in Atomic, which provides a tunneled or encapsulated network to Docker containers that isn't accessible from the host.
One of the on list responses talks about setting up a known IP space, taking a page from MS and using a local collision domain. AWS does this currently, making a metadata service available from all instances on 169.254.169.254.
This could be a solution for a Docker environment, where a host provides the trusted DNSSEC enabled resolver on known single and unchanging IP address. This avoids the special nature of the loopback address, but gives consistency for a number of different approaches.
-Matt M
On Thu, Jan 15, 2015 at 9:17 AM, Daniel P. Berrange berrange@redhat.com wrote:
On Thu, Jan 15, 2015 at 01:57:59PM +0000, P J P wrote:
Hello all,
Please see: -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver -> https://pjps.wordpress.com/2014/05/02/local-dns-resolver-in-fedora/
This is an upcoming F22 feature; it proposes to install a local DNSSEC
validating DNS resolver running at 127.0.0.1:53 on Fedora systems. This feature is already available in F21. One can easily run the local DNSSEC enabled resolver by
$ sudo yum install dnssec-trigger $ sudo systemctl enable dnssec-triggerd.service $ $ # disable and stop any existing DNS service, e.g., dnsmasq $ sudo systemctl start dnssec-triggerd.service
Though it works for most of the use-cases. Docker(or container)
applications
seem to face problems in accessing the host's DNS resolver at
127.0.0.1:53.
I'm no expert on Docker(or container) applications. I was wondering if
someone
could help in testing Docker(or container) applications with the local
DNSSEC
validating resolver on F21.
Any results from this exercise would be immensely helpful in fixing bugs
and
sorting out edge cases, thus making the solution robust and ready for
F22 release.
I'm willing to help in any way I could. As always, your comments and
suggestions
are most welcome!
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.
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.
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.
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.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct