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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel