On 30.4.2014 15:29, Simo Sorce wrote:
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P <pjp@xxxxxxxxxxxxxxxxx>, Pavel Šimerda
<pavlix@xxxxxxxxxx>, Tomas Hozza <thozza@xxxxxxxxxx>
To install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network
namespaces, like systemd-nspawn. When docker runs, it picks up the
current /etc/resolv.conf and puts it in the container, but the container
itself runs in a network namespace, so it gets its own loopback device.
This will mean 127.0.0.1:53 points to the container itself, not the
host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Any way we can redirect the connection to the host ?
On the host we cannot listen on 0.0.0.0 so we cannot make unbound
available through normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface
dedicated to let containers talk to other processes on the host maybe ?
(could even be other privileged containers). There is a question of what
addresses to use though ...
I don't see any nice way to make this "just work" in docker (i.e.
without changes to docker). Docker as well as the host sets up
127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to
the local loopback.
Yep, seen that.
The only ways to have a ip available to both the host and the container
are to either have a ip not in the 127.0.0.x range (thus this will be
forwarded to the default gw, i.e. the host) or to set up some kind of
forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs
to be done by docker, as its what sets up the network interfaces for the
container.
I thought as much, would it be rally bad to have docker forward via
iptables ? I guess the question really is, *how* do you do that ?
The local resolver listend on 127.0.0.1:53 *only* on the host, so it is
not like we can use iptables to forward to a routable address. Although
clearly we are on the same machine ... but I guess iptables is
namespaced so the one configured in the container has no way to see the
host's loopback ?
So, without changes to docker the option seems to be to set up another
local interface with address range different than 127.0.0.1 and have the
dns server listen to that.
And here comes the problem (actually 2)
1. the local caching resolver is meant to listen exclusively on
127.0.0.1:53 in the normal case, although I guess docker could be
allowed to poke at the configuration.
2. what address are you going to steal ? Just pull one out of the hat
like libvirt does for the default VMs network and just take possession
of another address in 192.168.X.0/24 ?
Sounds like we should try to define some "standard" network address to
do things like this instead, would it make sense to use the IPv4 network
some times ago microsoft bought and made available as a local collision
domain for these kind of things ?
They reserved the network in 169.254.0.0 as a local collision domain
where clients can auto-assign themselves an IP address and try to
communicate with neighbours in the same collision domain. I wonder if we
should perhaps hijack a subnet of that network, so we can avoid stealing
another /24 from 192.168 ?
IMHO we should consider approaches including Docker modification.
There has to be an ability to allow communication between containers (Apache
in one container and MySQL in second container).
Maybe with some slight modification it could route 127.255.255.254 to it's
"hypervisor". It could be even optional...
Other obvious approach is to allow Docker to use different /etc/resolv.conf
inside container (but still configured from outside of the container).
(Yes, it doesn't work today. It doesn't mean that it can't work in future.)
--
Petr^2 Spacek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
