F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
> On 11.06.2015 22:48, Dan Williams 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.
> 
> NetworkManager is pure network configuration manager in this scenario.
> We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> the current network configuration from it and act upon it. NM
> configuration will contain "dns=unbound".

Correct, and I personally have no problem with this.  NM is quite happy
to hand off DNS information wherever it has been told to do so.

But this is separate from the connectivity detection/hotspot issue which
I think we'll discuss more below.

> The cases when local (to the network you are connected to) DNS resolver
> does not support DNSSEC is handled by the logic in dnssec-trigger and
> dnssec-trigger script. Unbound is always configured in a way that it is
> able to do DNS resolution and DNSSEC validation. If this can not be
> done, the user is informed.

Right, and that's where most of this discussion lies, I think.

> >>>> 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.
> 
> If there is such situation, that Unbound fails all DNS lookups, then it
> is a bug. This is pure theory until you have some real situation. The
> logic is designed in a way to prevent such situations from ever happen.
> Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done
> by putting DHCP provided resolvers into resolv.conf. So in this
> situation Unbound it not used at all.
> 
> > 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
> 
> 1.1. Dispatch dispatcher with the network configuration change event.
> 
> > 2. NM updates DNS information
> 
> NM is not expected to touch resolv.conf in the intended default
> configuration.

My #2 was intended to be the same as your #1.1.  I was assuming
"dns=unbound" here.

> > 3. NM waits for some signal from unbound/dnssec-trigger about the
> > trustability of the DNS server
> 
> If you think NM needs to do some action (as I don't), we don't have
> problem with notifying NM (if you provide some API).

NM may need to do some action for connectivity checking.

> > 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?
> 
> The only trusted DNS resolver is the local Unbound. The DNS resolver
> from the network you are connected to is never trusted. It is just used
> in case it can provide all the necessary information to do the DNSSEC
> validation. Since using such data we are able to build the chain of
> trust and verify that the Answer is correct, there is no point in
> distinguishing if network provided resolver is trusted or not... it is
> not. This is the reason we do the validation locally.

Ok, I should rephrase my question to be clearer.  NM's connectivity
checking (which yes, does overlap in functionality with dnssec-triggers)
will resolve a hostname and attempt to contact it.  In this "untrusted"
state, will that hostname resolve to some address (either valid or
spoofed from a portal), or will NM get an error response from
gethostbyname/getaddrinfo-type calls?

Dan