Re: F23 System Wide Change: Default Local DNS Resolver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2015-06-17 at 13:17 +0200, Tomas Hozza wrote:
> On 12.06.2015 18:58, Dan Williams wrote:
> > 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?
> 
> How is NM doing the resolution specifically? Do you use the system stub
> resolver?

At the moment, yes.  But due this discussion, we have discussed handling
that outside the glibc resolver and then passing an IP address to our
connectivity checking code instead of a hostname, which would allow more
control over the process and not require writing the DNS servers to
resolv.conf until everything is ready.

> When doing the connectivity checking, NM should rather query the
> connection-provided DNS resolvers directly (via some other DNS library)
> and not via the system stub resolver (libc) that relies on entries in
> the resolv.conf.

Yes.  Although that requires a few other things, because in multi-homing
situations and for VPNs you need to make sure that the queries are
directed to the correct nameserver *over the link it came from*.  That's
a bit more complicated but I think we have all the support we need now
in glib/libsoup/etc to do it.

Dan

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux