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
