On Thu, 11 Jun 2015, Dan Williams wrote:
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.
dnssec-trigger prompts the user with a choice of "allow insecure DNS" or "cache only mode". The latter means "no new DNS and use what's already in the cache only".
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.
That is why HTTP redirection and DNS failure have to be detected by whatever is the "hot spot detector". Both items weigh in on triggering a hotspot logon window.
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.
Everyone is in agreement here I believe. No one particularly likes the dnssec-trigger ui. It was written as an desktop agnostic tool - for instance it works on Windows and OSX. I'd love to see this better integrated into gnome.
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
I don't know what 2) means. If it means rewriting /etc/resolv.conf or the unbound forwarder configuration, we have already lost if the DNS was malicious (and/or a hotspot DNS)
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?
dnssec-trigger currently detects the difference by also checking for an http hotspot redirect using http://fedoraproject.org/static/hotspot.txt If no http redirect, then DNS is broken and it tries to work around it by becoming a full iterative resolver or doing DNS over TCP or DNS over TLS. and if it all fails, presents the "insecure or cache only" dialog. But, if I could have my "ideal scenario", things would be a little different: 1) NM detects a new nework, but doesn't tell the applications that there is network connectivity yet. So firefox won't throw HTTPS warnings and pidgin/IM won't throw https warnings. Because as far as they know the network is still down. 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using a dedicated container and any DNS requests in that container are thrown away with the container once hotspot has been authenticated. This would allow us to never have resolv.conf on the host be different from 127.0.0.1. (currently, it needs to put in the hotspot DNS servers for the hotspot logon, exposing other applications to fake DNS) 3) dnssec-trigger updates the unbound DNS configurtion and tells NM to proceed. NM tells the applications there is new network connectivity. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
