F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams <dcbw at redhat.com> wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >> > decision needs to then be made by the system. I believe that's been
> >> > mostly due to lack of time for the various parties to sit down and
> >> > plan and then program this further.
> >>
> >> We should try to make that happen.
> >
> > Unfortunately the Proposal doesn't say anything about how this will
> > actually work, which is something NetworkManager needs to know.  It also
> > fails to address the failure cases where your local DNS doesn't support
> > DNSSEC or is otherwise broken here out of no fault of your own.
> >
> >> > >I see that there's a "hotspot sign on" option if you right click on the
> >> > >icon. How does this work with Network Manager and GNOME's captive
> >> > >portal detection?
> >> > I have never seen those work except for when the backend was down and
> >> > I got a stream of false positives. But possibly that is because I've used
> >> > dnssec-trigger for years now and it might win the captive portal
> >> > detection race. There are some bugs once in a while but overal it works
> >> > pretty reliably.
> >>
> >> I think that's probably it — the race. The hotspot signon thing works
> >> for me at coffeeshops. Or it did before I enabled this feature. We'll
> >> see now!
> >
> > So, if you're behind a portal then unbound could potentially fail all
> > DNS lookups.  That means that NetworkManager's connectivity detection,
> > which relies on retrieving a URL from a known website, will fail because
> > the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> > detection will also fail.  That kinda sucks.
> 
> I think that part of the problem is that there are too many
> implementations of captive portal detection and too many
> half-thought-out implementations of what do do if a captive portal is
> detected.
> 
> I think that, on a well-functioning system, if I connect to a wireless
> network, something should detect if I'm behind a captive portal.  If
> so, I should get a stateless browser that clearly indicates that it's
> a captive portal browser, probably lives in a sandbox, and sees the
> raw view of the network (no local DNSSEC validation).  We have network
> namespaces -- the browser part is doable even in a scenario where we
> wouldn't want to expose the incorrect view of DNS or some other aspect
> of the network to normal applications.   (Heck, on a configuration
> where we want to use a VPN over untrusted wireless, we could avoid
> exposing the untrusted wireless network to applications other than
> captive portal login at all.)
> 
> Please note that the current GNOME captive portal mechanism is
> blatantly insecure, and I've already filed a bug report with no
> resolution.  I'm not disclosing a subtle 0-day here -- the insecurity
> is fairly obvious.  I'll probably post to oss-security soon, but
> that's a somewhat separate topic.
> 
> Once we determine that there's no captive portal or that we've logged
> in to it, we should validate DNSSEC and otherwise behave sensibly.  If
> the network is screwed up enough that normal DNSSEC can't get through
> the DHCP-provided resolver (which happens -- I've seen ISPs that
> tamper with DNS results for www.google.com), then we should tunnel
> around it.  IIRC dnssec-triggerd already supports this.

So it sounds like there are two levels here:

1) connectivity detection and hotspot login using the network-provided
DNS servers, which are quite possibly insecure and/or broken

2) once that is all done, handling DNSSEC issues if the network-provided
DNS servers are insecure/broken.

Which is fine; I'm mostly concerned with #1 at this point because I
don't think NetworkManager has much to do with #2 since it already has
mechanisms to push the network's DNS servers to whatever wants it
(unbound, etc).

> >
> > While I'm sure the dnssec-trigger panel applet works great for some
> > people, I think the GNOME team would rather have the portal
> > functionality in the existing GNOME Shell indicator.  There is nothing
> > wrong with having DNSSEC enabled and part of the portal detection
> > scheme, but the UI handling portals is clearly a desktop-specific
> > decision.
> 
> This hasn't worked so well in the past.  Back when NM provided its own
> UI, that UI tended to work.  These days I frequently notice the
> gnome-shell UI for networking, bluetooth, etc missing features that
> are supported by the backend or just straight-up not working.
> > So whatever we need to do in NM to enable the workflow that
> > desktops need is what we'll end up doing...  Ideally the process goes
> > like this when unbound/dnssec-trigger are installed:
> >
> > 1. NM connects to a new network
> > 2. NM updates DNS information
> 
> Updates what information to what?  resolv.conf should be more or less invariant.

I was unclear.  Here I mean "do whatever the config files say to do"
which is either write resolv.conf, not touch resolv.conf at all
(dns=none), or send DNS to something else (dns=unbound or dns=dnsmasq).

> > 3. NM waits for some signal from unbound/dnssec-trigger about the
> > trustability of the DNS server
> > 3a. if the DNS server is trusted, NM continues with its connectivity
> > check
> > 3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
> > do we distinguish between "portal" and simply that your local DNS
> > doesn't support DNSSEC or is otherwise broken, if we cannot resolve the
> > address of the connectivity server?
> 
> I smell a turf war, sadly.
> 
> I don't think that "local unbound using dnssec-triggerd isn't NM"
> should be a show-stopper.  I'd like the see the result work correctly,
> and, honestly, if gnome-shell isn't part of the solution, then that's
> probably a good thing.  Clearly it should be integrated enough with NM

I think the *UI* for connectivity indication and portal login certainly
is a desktop specific task, because it's part of the network connection
user experience.  Whether that's GNOME or KDE or LXDE or whatever
doesn't matter, but all those environments have preferred ways of
interacting with network connections and portal login will need to be
part of that.

The backend that actually does the connectivity checking (to detect
portals or whatever) doesn't need to be part of the UI workflow, and
could certainly be provided by a small, simple service that does this on
request of things like NM or dnssec-trigger or GNOME Shell or KDE or
whatever.  If that's the path forward, I have thought to contribute
there as well.

> to be aware of connectivity changes, and it should probably integrate
> more deeply than that, but if the end solution bypasses NM's captive
> portal detection entirely, that doesn't seem like an a priori problem
> to me.

I honestly don't care much where the checking happens, but NM has
connectivity indication as part of it's API and we have to keep that for
a while, whether or not the implementation changes.  But there are other
considerations about what does the checking as it relates to NM, because
there are many consumers of it and not all of them will install unbound
or dnssec-trigger.

> Merging all of dnssec-triggerd into NM might be a decent solution.

Honestly I'd rather see a very small, single-purpose daemon (say,
'connectivityd' or whatever that has one simple job, to do the checking
upon request of NM/UI/whatever.  DNSSEC failures would get handled
separately; for example, could more of the failure-type logic be pushed
to unbound instead, since it's the resolver here?

> Keep in mind that a good DNSSEC solution is fundamentally tied to
> captive portal login.  There are probably many captive portals behind
> which it's impossible to get DNSSEC before login but where, once
> logged in, tunneled or even normal DNSSEC is possible.

Right; to me this says that we simply don't tell the rest of the system
that we're connected until we've gone through portal login.  But
whatever does connectivity checking and whatever UI does portal login
would have access to the network-provided DNS servers (untrusted of
course) to complete their jobs, and finally when it's indicated that
we're logged in do apps start using the network DNS servers.  Or if
those are broken, tunneled servers or something.

Dan