Integration of Unbound and NetworkManager on Slackware

In a previous note, I described how to enable DNSSEC validation on Slackware using a local resolver (Unbound) coupled to dnssec-trigger. Since then, I have modified my Slackware setup in two ways:

NetworkManager installation and setup

I installed NetworkManager using the package provided in Slackware64 14.1, and enabled it to start by setting the executable bit on /etc/rc.d/rc.networkmanager.

In NetworkManager’s main configuration file /etc/NetworkManager/NetworkManager.conf, I hade to change the following line




to have NetworkManager use dhclient instead of dhcpcd to perform DHCP auto-configuration. I found that using dhcpcd led to some weird problems when connecting to a dual IPv4/IPv6 nework—notably, some variables supposed to be set in the environment of NetworkManager’s hook scripts were not set when using dhcpcd.

Then, I reseted Slackware’s /etc/rc.d/rc.inet1.conf so that the /etc/rc.d/rc.inet1 script does not activate any network interface, in order to let NetworkManager do its job.

From that moment on, the only task of the /etc/rc.d/rc.inet1 script is to activate the loopback interface. It would thus be possible to get rid of that script completely and replace it by a much simpler script which would do only that.

With NetworkManager up and running, I used nm-applet, the NetworkManager, to actually configure the network connections.

Integration with Unbound

Getting NetworkManager to work with Unbound as a local resolver caused one little problem.

Upon establishing a connection, NetworkManager attempts to fill the /etc/resolv.conf file with the nameservers that it deems appropriate for the network it just connected to (in general, the nameservers that were indicated in the DHCP reply). But on my system, that file should always contain nothing else than the following line:


so that all name resolution requests always go to the local resolver Unbound. Unfortunately, as far as I can tell NetworkManager does not provide any configuration option to prevent it from always overwriting the /etc/resolv.conf.

The simplest method to overcome that problem is to set the immutable attribute on the /etc/resolv.conf file:

# chattr +i /etc/resolv.conf

so that the file cannot be overwritten. It works, although NetworkManager will regularly complain in its log that it failed to “update the DNS configuration”—that’s the desired effect.

However, a cleaner method in my opinion is to inform NetworkManager that there is a local resolver around and that /etc/resolv.conf should point to it. For that, NetworkManager has the concept of “DNS plugins”, which it can use to interact with a local resolver. As of NetworkManager-, the only available DNS plugin is nm-dns-dnsmasq, allowing NetworkManager to interact with Dnsmasq.

I patched NetworkManager to add a new DNS plugin called nm-dns-none. It is a “dummy” plugin that really does nothing, apart from telling NetworkManager that a local resolver is present, thus leading NetworkManager to write nameserver in the /etc/resolv.conf file.

NetworkManager- (text/x-diff, 5.6K)

Once applied, the patch will have no effect unless the plugin is specifically activated by putting the following line in NetworkManager’s configuration file:


UPDATE (2014/12/21): NetworkManager 1.0.0, released on December 19th, 2014, already includes a similar mechanism (using the same dns=none syntax) and the above patch is thus no longer necessary.

Hook scripts

Before switching to NetworkManager, I used to have my DHCP client run a custom script after establishing a connection. This script configured the NTP client, mounted remote filesystems, and performed some other tasks depending on the network my laptop was connected to.

NetworkManager allows to run the same kind of hook scripts, if they are stored in /etc/NetworkManager/dispatcher.d. Converting a dhcpcd script into a NetworkManager script is straightforward, but NetworkManager does not allow one of its script to run for more than about 3 seconds before killing it. Consequently:

  1. This decision was inspired by an advice from Stéphane Bortzmeyer, the rationale being that dnssec-trigger can check whether the provided nameservers are DNSSEC-capable but cannot ensure that they are not liars.