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? 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. Tomas > Dan > -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
