F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

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.

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

Dan