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:

• I no longer use dnssec-trigger: Unbound now always do the DNS resolution and validation itself (by querying the authoritative nameservers); the nameservers provided by the local network are ignored, whether they are DNSSEC-capable or not.¹
• I now use NetworkManager to, well, manage network connections.

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

dhcp=dhcpcd

by

dhcp=dhclient

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.

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:

nameserver 127.0.0.1

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-0.9.8.8, 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 127.0.0.1 in the /etc/resolv.conf file.

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

dns=none

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:

• several short hook scripts, each doing only one task, should be preferred over a single hook script doing everything;
• time-consuming tasks, such as mounting a network share, should be run in the background.

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.

10 March 2014