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". 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. >>>> 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. > 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). > 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. > Dan > I would like to add that this already works without any other interaction with NM. I agree that the notifications from dnssec-trigger are not ideal. I'm going to contact some GNOME guys and ask them for help. Thank you for your comments! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
