Local DNSSEC resolver and Docker(containers)
nzwulfin at gmail.com
Thu Jan 15 14:57:12 UTC 2015
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
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.
On Thu, Jan 15, 2015 at 9:17 AM, Daniel P. Berrange <berrange at redhat.com>
> 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)
> > seem to face problems in accessing the host's DNS resolver at
> > I'm no expert on Docker(or container) applications. I was wondering if
> > could help in testing Docker(or container) applications with the local
> > validating resolver on F21.
> > Any results from this exercise would be immensely helpful in fixing bugs
> > 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
> > 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
> the filesystem namespace, but with separate network namespace and so no
> have access to the same 127.0.0.1:53 binding. And libvirt-sandbox can
> 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.
> |: 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 at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cloud