On Thu, Jun 09, 2016 at 10:44:32AM +0200, Martin Pitt wrote:
> 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).
Yep, that sounds reasonable to me.
> 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.
Well, even on the phone I'd argue that this is a privacy concern unless
we prevent apps from doing DNS queries by default.
I wouldn't want a random app I installed to start figuring out what
websites I'm accessing and sending that information back to its author
to then get sold.
> Thanks,
>
> Martin
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
