Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

Tomas Hozza thozza at
Fri Jul 17 15:40:56 UTC 2015

Hello all.

I would like to share the outcome of the discussion between GNOME and NM developers
and the "Default DNS resolver" [1] Change for F23.

The full summary can be found here [2] and recording here [3] is anyone is interested.

Integration points:
- Captive portal detection
- Captive portal handling
- User interaction

Points we agreed on:
* Captive portal detecion
  * NM side
    * NM will be the only daemon doing Captive portal detection
    * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits signal before network is "up"
    * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a specific device until there is no more portal
    * NM regularly does the Captive portal detection (connectivity check) to determine if the login using GNOME was already done
    * Once the login was done and Internet connectivity is detected, NM triggers some event in nm-dispatcher (or something like that)
  * GNOME side
    * GNOME Shell does not do detection itself, but relies on the NM (as already done)
    * GNOME is watching the change of "connectivity state" property in NM
  * dnssec-trigger side
    * Does not do any detection
    * does not do any user interaction
    * Only relies on events triggered by NM and acts based on the connectivity status

* Captive portal handling (login)
  * GNOME side
    * If Captive portal is detected, then browser window is launched
    * The browser window ls launched with LD_PRELOAD ( as resolv.conf override
    * GNOME should fetch the connection-provided DNS servers using NM API (existing) and use those for LD_PRELOAD solution
  * dnssec-trigger side
    * does not do any user interaction
    * Only relies on events triggered by NM and acts based on the connectivity status

* User interface / user interaction
  * Fedora Workstation product
    * GNOME shell
      * informs the user about the Captive portal
      * launches the window 
    * dnssec-trigger
      * the applet will be split into separate package and not installed by default (already done)
      * if all falbacks fail, it switches automatically to "Insecure" mode (no DNSSEC validation) without user interaction
        * automatic switch to insecure mode will be possible to turn off using configuration file for expert users
        * a notification can be emited about switching to insecure mode (so far by default OFF)
  * Other desktops / Spins
    * dnssec-trigger applet
      * should handle the UI that is usually handled by GNOME Shell (if there is not any specific Spin implementation to do that, i.e. if GNOME is not in use)
      * Captive portal detection will be still done in NM

* under discussion:
  * notification can be turned OFF by default, but configurable in config file for expert users - unfortunatelly this will not create pressure on admins to fix the networks
  * alternative: display a message which will say that local network is broken and that admin should be woken up:
    * 'Your network is seriously broken. Go and kick your network admin NOW!
    * This broken network will stop working from Fedora 24 on because it does not support DNSSEC. (Tell this to your admin!)'


Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

Red Hat Inc.       

More information about the devel mailing list