Stéphane Graber [2016-06-07 16:47 -0400]:
> > > 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.
Well, I *was* talking about NSS.. If browsers do the above, that's
still incomplete, as every other NSS module is still being
disregarded. So my sympathies are limited, but I know I can't win a
war with "Use our default browser Firefox then" :-)
If a program wants to ignore NSS and reimplement DNS lookups, then
indeed they either need a local DNS server or do the resolved lookup
over D-Bus directly.
> 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.
Still not entirely true, but certainly closer to the actual result
than without a DNS server.
> 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.
Right, and it would also require changes to
NetworkManager/networkd/ifupdown to actually push changes into that,
which is quite some amount of work.
So that, or we wait until resolved actually offers the option to run a
local DNS server (upstream is planning to do that soon actually, for
precisely the Chromium case). Then we can put "127.0.0.N:53" into
/etc/resolv.conf for programs which don't do NSS (Chromium & Go), and
keep libnss-resolve for everything else, which will then completely
ignore /etc/resolv.conf.
In both cases we lose the feature that /etc/resolv.conf shows the
"real" nameservers, but as we can't have that without Chromium &
friends doing proper NSS lookups or D-Bus calls, this seems to be
infeasible at the moment. (But also not that important -- we can still
put a comment into it that shows the command to see the real DNS
servers).
So, how about this as a plan of action:
- Revert the NetworkManager change for now, and do start a local
dnsmasq again, so that /etc/resolv.conf will point back to
127.0.1.1.
This will keep the current behaviour on the desktop for chromium's
sake, but do proper NSS resolution for everything else, including
on the server.
The main downside is that we temporarily have one extra process on
the desktop (resolved *and* dnsmasq).
- Once resolved gets capable of listening to 127.0.0.53:53, configure
it like that and drop NetworkManager's dnsmasq again.
This should be "weeks" rather than "releases". If not, we can
always choose to disable resolved around 16.10 beta too, if the
extra process on desktop is a concern.
Does that sound acceptable? If not, I'd just revert the whole thing
for now, as I'm afraid I won't have time to rework
resolvconf/networkd/NetworkManager etc. to maintain a local dnsmasq
instance that also applies to servers. (But we could still keep the
adjusted spec for the future, then).
As for security issues, AFAICS the remaining ones are:
- Investigate the DNS cache poisoning corner case. With 16 bit ID
and 16 bit port randomization this is considerably hard to do, the
attach scenario only makes sense on a non-sniffable network (wifi
is always sniffable, and I'm not convinced that ethernet networks
are completely unsniffable!). So I think we should continue to
discuss this.
- The issue of being able to determine whether another user on the
same computer visited a particular address. That's not relevant
for home setups, but it is for universities, companies etc. where a
lot of people use the same DNS server. OTOH local caching gives you
a lot of performance increase. So a compromise would be to provide
an option for this, and then turn caching on/off by default. E. g.
we absolutely want to turn on caching on single-user devices like
Ubuntu touch, but maybe not on desktop.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
