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

[Tomas Hozza]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-dnssec-trigger-hook-new_nm
Type: text/x-python
Size: 16046 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/dnssec-trigger/attachments/20140121/5e826440/attachment.py>