<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-29 17:15 GMT+02:00 Alexander Larsson <span dir="ltr"><<a href="mailto:alexl@redhat.com" target="_blank">alexl@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:<br>
> = Proposed System Wide Change: Default Local DNS Resolver =<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>
<br>
> To install a local DNS resolver trusted for the DNSSEC validation running on<br>
> <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a>. This must be the only name server entry in /etc/resolv.conf.<br>
<br>
</div>This is gonna conflict a bit with docker, and other users of network<br>
namespaces, like systemd-nspawn. When docker runs, it picks up the<br>
current /etc/resolv.conf and puts it in the container, but the container<br>
itself runs in a network namespace, so it gets its own loopback device.<br>
This will mean <a href="http://127.0.0.1:53" target="_blank">127.0.0.1:53</a> points to the container itself, not the<br>
host, so dns resolving in the container will not work.<br></blockquote></div><br></div><div class="gmail_extra">Good point; would it be fair to treat this as a blocker?<br><br></div><div class="gmail_extra">(This also assumes that the docker containers will use the same security policy as the host; i.e. that they will be administered by the same entity, no "docker hosting" businesses.)<br>
</div><div class="gmail_extra"> Mirek<br></div></div>