F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

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.

>
> 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.

> 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
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.

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

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.

--Andy