Hi all. I would like to start a new fresh discussion where we can hopefully converge towards successful integration of default DNS resolver with NetworkManager on Fedora Workstation (GNOME). I think there are (at least) two major issues that need to be resolved: - system-wide Captive Portal detection - proper UI integration How is dnssec-trigger integrated with NM ---------------------------------------- I'll start briefly with what dnssec-trigger does and how it is integrated with NM, so we are on the same boat. We use Unbound as local DNS resolver that does also DNSSEC validation. It needs to be configured with proper DNS forwarders in order to do the validation successfully. Dnssec-trigger is a daemon and script that reconfigures Unbound dynamically on every network change (using NetworkManager dispatcher). In our intended setup, dnssec-trigger handles the content of /etc/resolv.conf. It gathers all the current configuration from NM using libnm-glib. This means that we are able to handle any connection that NM is aware of, including VPNs and split DNS configuration. Our goal is to do DNSSEC validation whenever possible, therefore we have also public fallback Fedora infrastructure or DNS resolvers running on port 443. Since dnssec-trigger handles resolv.conf and reconfigures Unbound, NM's purpose is to do all the network configuration EXCEPT DNS related configuration. Captive Portal -------------- Dnssec-trigger also handles Captive Portal detection, since this situation is most of the times DNS spoofing attack and DNSSEC is exactly the mechanism that should protect users from such attack. Now we know that we have at least 3 components on the system, that are trying to do the same thing - Captive Portal detection: - dnssec-trigger - NetworkManager - GNOME Shell We don't have a problem with turning the detection off, however we need to agree on system-wide solution that works properly. We already know that the Captive Portal detection in NM relies on the system stub resolver, however after our previous discussion I was under the impression that there are some plans to rework it. Is this correct Dan? I hope that GNOME Shell somehow only displays the state provided by NM. Bastien, please correct me if I'm wrong and please elaborate on the details of what the functionality does (e.g. if you launch a new browser or so). In dnssec-trigger the detection is done by resolving a predefined hostname using DHCP-provided resolvers, downloading a remote file and then comparing the actual content with what was expected. This may not be perfect, but is mostly works. The important point is that DHCP provided resolvers are queried directly, not via system stub resolver. On the other hand, if NM dispatcher would be able to notify other services in case of detected Captive Portal, dnssec-trigger would be able to add the correct DHCP-provided resolver into the resolv.conf for the purpose of Logging into the Captive Portal. This is mainly due to the browser window using system's stub resolver. UI integration -------------- Now the dnssec-trigger comes with not really well integrated UI (dnssec-trigger panel) [2]. The panel is written in GTK2 and resides in the already deprecated status panel (on the bottom of the screen). It is used mainly for the following interaction with the user: - Inform the user about Captive Portal, in case there is one (to allow user to switch into so called "hotspot signon mode") by pop-up window - enable user to switch to "hotspot signon mode" (basically insecure mode) manually - enable the user to reprobe DHCP-provided DNS servers if these are DNSSEC enabled - meaning to test if these are able to provide all the data needed for DNSSEC validation. - inform user in case the local network-provided DNS servers don't support DNSSEC and the local network blocks outgoing DNS communication on standard DNS ports and also when tunelled - in other words, user much choose between insecure mode or disconnecting from the network. This boils down to what we need from some new version of the UI that we need to be well integrated with GNOME: 1. Be able to inform user about some situations (Captive portal detected, network blocks all DNS communication, ...) and enable the user to take an action. (This could be possibly done by the notifications system in latest GNOME) -> this may be solved also in GNOME already, and may be OK if done technically correctly. Please note my note earlier on NM notifying other services when Captive Portal is detected 2. Possibly have some indicator showing if the system is in "Secure" or "Insecure" state. 3. Enable the user to switch between those two states manually 4. Additionally enable the user to trigger the reprobe of connection-provided DNS resolvers and display result of the probe (last one). -> this should not be needed for regular use. It is more of a debugging tool [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver [2] http://www.nlnetlabs.nl/projects/dnssec-trigger/#screenshots I'm all for simple and clean integration. Let's identify specific solutions and pieces we can start working on. Thanks. 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
