I'm bringing up an idea of splitting the pythonic NetworkManager dispatcher script written by Tomáš into two peaces. The original script doesn't need any modifications and could be installed e.g. as /usr/libexec/dnssec-trigger-update, while the new script will be installed in /etc/NetworkManager/dispatcher.d.

The new script could look like:


#!/bin/sh
#
# Script to notify dnssec-trigger that the DNS configuration in NetworkManager
# may have changed.

# NetworkManager reportedly doesn't pass the PATH environment variable.
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Future versions of NetworkManager will have an active unbound/dnssec-trigger
# plugin. Don't intervene when the new plugin is being used.
if [ -e /etc/NetworkManager/NetworkManager.conf ]; then
    grep -q '^dns=unbound\>' /etc/NetworkManager/NetworkManager.conf && exit 0
fi

# Exec the dnssec-trigger update script that uses NetworkManager API to gather
# all the necessary information.
if [ -x /usr/libexec/dnssec-trigger-update ]; then
    exec /usr/libexec/dnssec-trigger-update
fi


Rationale:

1) It will be much cleaner to avoid calling NetworkManager dispatcher.d scripts from anywhere else than NetworkManager dispatcher itself. Currently the dispatcher is being called from systemd services and a /usr/libexec file is much more suitable for that.

2) Notice the check for dns=unbound in NM configuration. Of course the check can be improved or expanded. But the basic idea is that the script will become a no-op when we turn on an actual Unbound plugin.

3) During the early stages of development, the Unbound plugin can simply call /usr/libexec/dnssec-trigger-update which won't have the check and therefore will work properly.

4) For upstream, dnssec-trigger-update can be thought of as a universal integration point, not necessarily specific to NetworkManager.

5) Notice the 'exec' when callling dnssec-trigger-update. If the pythonic update script is not installed, the execution would fall through and there could be a bash fallback right in the script.

6) With that in mind, the new script could including the dns=unbound safeguard could be safely merged into the existing shell script solution.


Further notes:

The dnssec-triggerd.service file would be updated to use the file directly which in turn would mean it could also perform detection of NetworkManager and could notify NetworkManager when appropriate. The good thing about the split is, that NetworkManager dispatcher event would not result in returning the notification back to NetworkManager.

This may also be treated as a preliminary step for the next of NetworkManager dnssec-trigger integration.