[Dnssec-trigger] New dnssec-trigger NM dispatcher script

Tue Jan 21 16:47:09 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tomas,

On 01/21/2014 04:33 PM, Tomas Hozza wrote:
> Hello.
> 
> For last couple of days I've been working on new dnssec-trigger 
> dispatcher script due to some issues in the current one that are
> hard to overcome in the current script.

Thank you for the contribution. Yes the python and NM -git version
dependency makes it hard to include it by default in the source; if NM
was released I could version-check for python and NM-<version> in
configure.ac and include it conditionally.

Best regards, Wouter

> The main reasons were: The script relies only on information
> provided via Environment variables set by NM when dispatcher runs
> the script. This results in some unwanted situations:
> 
> 
> 1. Imagine you boot up the system. NM is started before
> dnssec-trigger and unbound, therefore all informations about
> domains provided by existing connections are discarded.
> 
> So if you were already at the boot time connected to a network
> that provides domains via DHCP no forward zones were added for such
> domains into the unbound.
> 
> Till now there was no possible way how one could get those
> information from NM during the runtime, especially for VPN, but
> this is already fixed in the latest NM git snapshot.
> 
> 
> 2. Imagine you have two connections that provide the same domain. 
> One is VPN and one is not. In current situation the last connected 
> connection and by it provided NS would be used for that domain. By
> my opinion and by what I discussed with Pavel Simerda it makes more
> sense for the VPN to be preferred.
> 
> 
> 3. Imagine you have two connections that provide the same domain. 
> One is VPN and one is not. Forward zone for provided domain has 
> been added into unbound by the dispatcher script. If you then 
> disconnect the connection for which the forward zone has been 
> configured, it is removed by the dispatcher script. However even 
> there is another connection providing the same domain the forward
> zone is not added, because it is added only if the connection goes
> UP.
> 
> 
> Due to these reasons I rewrote the script into Python and used the
> NM libnm-glib Python bindings that allow one to get information for
> current active connections from NM. However for NM to support 
> everything correctly you need to use the latest 0.9.9.0 git 
> snapshot. Necessary patches are backported in Fedora 20+. There is
> still one issue with getting IPv6 addresses of nameservers, but
> Jiri Klimes (NetworkManager developer) is already looking into it
> so I expect a fix soon. I used python, since the logic is more
> complicated and also it was beneficial to use OOP in this case.
> 
> The new script works as follows:
> 
> A. It gets all active connections from NM that have provided some
> NS. It gets information if the connection is VPN, or is marked as
> default connection by NM (for IPv4 or IPv6).
> 
> B. Global forwarder are configured using dnssec-trigger-control. 1.
> Only active connections marked by NM as default (4 or 6) are
> filtered. 2. NSs provided by such connections are combined into one
> list (both IPv4 and IPv6 addresses) and passed to
> dnssec-trigger-control.
> 
> C. Forward zones for domains provided by active connections are
> configured using unbound-control 1. Only active connections with
> domains provided are filtered. 2. Dictionary for "domain" ->  is
> constructed, so it is clear which NS should be used for the
> particular domain (forward zone). - If there are two connections
> that provide the same domain and one of them is VPN, the VPN
> connection is preferred. - If there are two connections that
> provide the same domain and none of them are VPNs or both are VPNs
> and one of them is marked by NM as default (for IPv4 or IPv6). - As
> it is unclear what should be done if there are two connections 
> providing the same domain and none of them is VPN or both are
> VPNs, one of the connections is used (without specific preference).
> Once there is some consensus on what should be done in such
> situation the logic can be adjusted without problems. 3. Previously
> configured Forward zones for non existing connections are removed
> from unbound. 4. Previously configured Forward zones for
> connections which UUID is different than the UUID of connection
> that should be used for the domain are removed from unbound. -
> example: you are connected via wire to network that provides 
> "example.com" domain therefore it has been configured as forward 
> into unbound. But after that you are connecting to a VPN that 
> provides also "exmaple.com" domain, so the VPN provided NS should
> be used and previously configured zone needs to be removed first. 
> 5. Still configured forward zones in unbound are removed from the 
> dictionary of zones that need to be added to unbound. - This needs
> to be done to ensure that forward zones configured manually in
> unbound.conf are not replaced by dynamic ones. 6. Forward zones
> from dictionary are configured into unbound.
> 
> 
> I also extracted the option for whether to configure secured or
> unsecured forward zones to /etc/dnssec.conf file. This was done so
> the option can be reused also by other tools, not only
> dnssec-trigger, as we (me and Pavel Simerda) plan to implement
> equivalent functionality and unbound plugin for NetworkManager. The
> configuration file does not need to exist, the default behaviour is
> also specified in the script itself. The option name is
> "validate_connection_provided_zones" since from our point of view
> it is more self-explanatory than "forward zones" used unbound 
> terminology.
> 
> 
> Due to the very latest NM version needed for this script to work I
> would not recommend it to replace the current shell script. It
> would be enough to include it in a contrib/ subdir.
> 
> 
> Even tough I would like to hear some feedback on it.
> 
> Thank you in advance.
> 
> Regards,
> 
> Tomas Hozza
> 
> 
> 
> _______________________________________________ dnssec-trigger
> mailing list dnssec-trigger at NLnetLabs.nl 
> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3qSNAAoJEJ9vHC1+BF+NrucP/0Tp7/xCvn+BWAP+g6aa52ZD
g6gH2PvO7GZpRTpVIxW/PrHbXvsTCzECB+H9+lO7TIga93IBHSzqo59VpApQzTWE
cLr6psX3FS2bN4Qn9owqPou4nC1qANM44BU+dDKsfGnfTEcir+Y8nvEESGO04br9
B38W4k9F3i8VdhdoZSTzVGyXaWsoDPuNbuRTnwu8qC2M5z0tbWJd7ItIv6YM8aih
M/FBJHe1V11+Twxf5ePvzmOxkmrUOGS9AOIq7CgysCy4pm/q/8IHcr+jXgHBia9n
jV482sNwooggFUb893TEXnarUvkbXeGAO/oNbxLAL7OikphCC/y0JmnrL/PgNM8a
8mdYFt2MO38E97byiC1PVwcmGr5GwwDpQImux/wkPNTkRy0rOzx0LcwHoRc1g2D4
XsdKNMDehRTWGZoNPjucPVh2pPauJzTggQJsvX6I10VmtOcGyGqBMH9Ewi/aGb28
j6v5SkNoiNOu7giziLH11116NCkaNmufmHFnW7Lq84EP0dQhoIK4CZsMp33aj4JB
wBXqdlwdYVcZ1O3GjAj9b5BMc9h9aMKlazrcasyt9+lAbWKCaS7fJnfADRSSJXUO
3zht6AYs/if8dRLd9RJQnu/6g3NI/trptn3ffoh6fmLVSCaN4NdTen5o0bSkDitV
7qaXV2IIexB9hesg03VS
=upXr
-----END PGP SIGNATURE-----