ANN: DNS resolver changes in yakkety

[Marc Deslauriers]

On 2016-06-09 11:44 AM, 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).
> 
> 
> 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.
> 

Both of those security issues are resolved by adding an option to disable
caching. The remaining question is whether or not to disable caching by default.

Both issues are pretty low-severity. I believe turning on caching will improve
the user experience, so I'm slightly conflicted on what the default should be.

If the option to turn it off on multiuser systems is easy, I believe I'm leaning
toward leaving caching on by default. Other operating systems apparently enable
system-wide DNS caching by default, and administrators of multiuser systems can
easily turn it off it's a concern to them.

For touch and confined applications, if this turns out to be a privacy concern
for our users, we can either turn off caching by default for the touch devices,
or we can disable caching only for confined applications by adding some sort of
AppArmor integration.

Marc.