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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct