On Tue, Jun 07, 2016 at 09:30:49PM +0200, Martin Pitt wrote:
> Stéphane Graber [2016-06-07 12:22 -0400]:
> > So, minus the security problems that have been mentioned so far, I can't
> > think of any major problems with using resolved on servers.
>
> It would be as you said that some Go programs and python-dns don't use
> NSS and thus won't respect per-domain DNS servers (nor mdns, or
> nss-ldap, nss-winbind, nss-mymachines, etc.)
Right, but that's status quo on the server as there currently is nothing
using per-domain DNS there.
> > We'll definitely want to make sure that it doesn't start in containers
> > by default as that'd significantly increase the process count for no
> > good reason on systems with hundreds or thousands of containers.
>
> Yes, simple enough to add ConditionVirtualization=!lxc to resolved or
> dnsmasq.
>
> > And it'd be nice if there was a way to only have resolved run when we
> > have multiple DNS servers as otherwise, with caching disabled (and I
> > suspect we will turn it off), it'd just make things slower.
>
> It still provides DNSSEC validation, if only in "allow downgrade" mode
> for now (we have to start slow). And there's no problem in caching
> these.
>
> > Yeah, we certainly don't want dnsmasq running on servers.
>
> So if we can't use resolved because of Go programs, and shouldn't use
> dnsmasq (or similar DNS servers) on servers, then what *should* we use
> on servers then?
As I said, I don't have a problem with resolved on servers, so long as
we don't degrade our security story (so having caching off and the other
issues investigated).
>
> > And so long as having a common solution can be done without regressions
> > and without hand wavy answers like "web browsers will just have to
> > switch to some new systemd DBUS API", I don't mind the change.
>
> Oh, come on.. NSS is neither a systemd API nor is it "new" in any
> sense of the word.. it's decades old, and with not doing it you have a
> lot of other breakage/restrictions. But, as Go is apparently our new
> hotness, we have to live with it I guess.
I wasn't talking about NSS. I was talking about web browsers or any other
piece of software that needs the complete DNS reply and still should use
the per-domain DNS servers as setup by Network Manager.
Today everything works because /etc/resolv.conf points to 127.0.1.1
which then does the per-domain DNS correctly. So whether you hit it
directly or through NSS, you get the same result.
With resolved, if you query things directly through DNS, you'll only hit
the upstream forwarders as defined in /etc/resolv.conf which will not
reflect per-domain DNS servers.
You'd then have to either query it through NSS which would mean loosing
access to the complete DNS reply or query it through some direct DBUS
API which would mean extra work for downstreams.
> > In order to reach your goal without breaking anything, I suspect we'd
> > either need to have resolved offer a local DNS server which can be put
> > ahead of everything else in /etc/resolv.conf, similar to what we do with
> > dnsmasq.
>
> Turning resolved into a DNS server (which it doesn't aim/want to be)
> would be rather pointless IMHO. Then we can just as well use dnsmasq
> everywhere, I see little point in having two different solutions on
> desktop/server. Are there any objections to that? (It makes using
> networkd significantly harder, but we can patch this in principle)
We don't have anything right now that lets you manage such a dnsmasq, so
some integration code would have to be written for resolvconf I'd expect
to setup and manage that dnsmasq instance.
> Martin
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
