F23 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Thu, 11 Jun 2015, Dan Williams wrote:

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

dnssec-trigger prompts the user with a choice of "allow insecure DNS" or
"cache only mode". The latter means "no new DNS and use what's already
in the cache only".

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

That is why HTTP redirection and DNS failure have to be detected by
whatever is the "hot spot detector". Both items weigh in on triggering
a hotspot logon window.

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

Everyone is in agreement here I believe. No one particularly likes the
dnssec-trigger ui. It was written as an desktop agnostic tool - for
instance it works on Windows and OSX. I'd love to see this better
integrated into gnome.

> 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

I don't know what 2) means. If it means rewriting /etc/resolv.conf or
the unbound forwarder configuration, we have already lost if the DNS
was malicious (and/or a hotspot DNS)

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

dnssec-trigger currently detects the difference by also checking for an
http hotspot redirect using http://fedoraproject.org/static/hotspot.txt
If no http redirect, then DNS is broken and it tries to work around it
by becoming a full iterative resolver or doing DNS over TCP or DNS over
TLS. and if it all fails, presents the "insecure or cache only" dialog.

But, if I could have my "ideal scenario", things would be a little
different:

1) NM detects a new nework, but doesn't tell the applications that there
    is network connectivity yet. So firefox won't throw HTTPS warnings
    and pidgin/IM won't throw https warnings. Because as far as they know
    the network is still down.

2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
    a dedicated container and any DNS requests in that container are
    thrown away with the container once hotspot has been authenticated.
    This would allow us to never have resolv.conf on the host be
    different from 127.0.0.1. (currently, it needs to put in the hotspot
    DNS servers for the hotspot logon, exposing other applications to
    fake DNS)

3) dnssec-trigger updates the unbound DNS configurtion and tells NM to
    proceed. NM tells the applications there is new network connectivity.

Paul