<div dir="ltr">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.<div><br></div><div>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 <span style="color:rgb(0,0,102);font-family:'Courier New',Courier,mono;font-size:12px;background-color:rgb(238,238,238)">169.254.169.254.</span></div><div><br></div><div>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.<br></div><div><br></div><div>-Matt M</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 9:17 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jan 15, 2015 at 01:57:59PM +0000, P J P wrote:<br>
> Hello all,<br>
><br>
> Please see:<br>
> -> <a href="https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver" target="_blank">https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver</a><br>
> -> <a href="https://pjps.wordpress.com/2014/05/02/local-dns-resolver-in-fedora/" target="_blank">https://pjps.wordpress.com/2014/05/02/local-dns-resolver-in-fedora/</a><br>
><br>
><br>
> This is an upcoming F22 feature; it proposes to install a local DNSSEC<br>
><br>
> validating DNS resolver running at <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> on Fedora systems. This<br>
> feature is already available in F21. One can easily run the local DNSSEC<br>
> enabled resolver by<br>
><br>
> $ sudo yum install dnssec-trigger<br>
><br>
> $ sudo systemctl enable dnssec-triggerd.service<br>
> $<br>
> $ # disable and stop any existing DNS service, e.g., dnsmasq<br>
> $ sudo systemctl start dnssec-triggerd.service<br>
><br>
> Though it works for most of the use-cases. Docker(or container) applications<br>
> seem to face problems in accessing the host's DNS resolver at <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a>.<br>
><br>
> I'm no expert on Docker(or container) applications. I was wondering if someone<br>
> could help in testing Docker(or container) applications with the local DNSSEC<br>
> validating resolver on F21.<br>
><br>
> Any results from this exercise would be immensely helpful in fixing bugs and<br>
> sorting out edge cases, thus making the solution robust and ready for F22 release.<br>
><br>
> I'm willing to help in any way I could. As always, your comments and suggestions<br>
> are most welcome!<br>
<br>
</span>NB this won't just be a Docker problem. It has the potential to affect any<br>
container technology. eg a simple libvirt LXC container can be setup sharing<br>
the filesystem namespace, but with separate network namespace and so no longer<br>
have access to the same <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> binding. And libvirt-sandbox can setup<br>
KVM guests where the guest runs off a readonly passthrough of the host's /<br>
but obviously the KVM guest will not see any host network interface.<br>
<br>
I think that probably the solution will have to involve any such apps doing<br>
a bind mount on /etc/resolv.conf to reply the file with alternative content<br>
Historically they tried to avoid that because doing a bind mount onto<br>
/etc/resolv.conf would prevent the host OS from unlinking/replacing that<br>
file. With this dnssec change though, /etc/resolv.conf will never get its<br>
content changed once the OS is booted, so this bind mount problem would<br>
no longer be an issue.<br>
<br>
An alternative would be for the container technology to setup some kind<br>
of port forward, so that <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> inside the container get magically<br>
forwarded to <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> outside the container.<br>
<br>
A slightly off the wall idea would be for the resolv.conf to not mention<br>
<a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> at all, and instead listen for DNS requests on a UNIX socket<br>
in the filesystem. eg have resolv.conf refer to "/var/run/resolv.sock".<br>
A container starting a new network namespace, but sharing the mount<br>
namespace could still access that UNIX socket. If they had a private<br>
mount namespace, they could bind mount the UNIX socket in. The big problem<br>
is that while you could probably update glibc easily enough, there are<br>
probably a fair few apps that directly parse /etc/resolv.conf and would<br>
almost certainly get confused by a UNIX domain socket. So this idea would<br>
probably not fly.<br>
<br>
Unless perhaps glibc could just try /var/run/resolv.sock unconditionally<br>
and only if that's missing, then fallback to /etc/resolv.conf which would<br>
contain <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> still. That way most apps would jsut work with the<br>
UNIX socket and resolv.conf would still have a TCP socket for those which<br>
need it.<br>
<br>
All the solutions need some work - I can't see any obvious way of making<br>
the containers problem you describe "just work" without the developers<br>
of such software doing some work.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br>
</div></div></blockquote></div><br></div>