ANN: DNS resolver changes in yakkety

Stéphane Graber stgraber at ubuntu.com
Thu Jun 9 17:07:56 UTC 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20160609/859ae5f3/attachment.pgp>


More information about the ubuntu-devel mailing list