On one of our Raspberry Pis with Raspbian “Buster” image we had a strange problem in combination with a USB mobile stick: The Wireguard VPN client could not connect correctly to the Wireguard server again and again when starting the Pi. The error log said that the hostname of the Wireguard server could not be resolved in the client configuration.

A possible cause for this could be that at the time the Wireguard server was started, the internal DNS resolver of the mobile stick (NAT/router operation) was not yet operational and resolution failed because of this. To confirm the theory and fix the error, a default name server should now be introduced, which is always the same regardless of the network connection and is available immediately.

Usually the currently used DNS resolver is automatically entered into the file /etc/resolv.conf by the network management - this is also the case with Raspbian. In most cases, the DNS resolver assigned by the DHCP server of the local network is entered here.

In our case the setup is a bit more complicated: Since we run Dnsmasq on the Raspi for other purposes, it has taken control of DNS name resolution and entered itself (127.0.0.1) into /etc/resolv.conf. However, Dnsmasq itself only takes over the role of a “caching DNS resolver” - it does not make queries up to the DNS root servers itself, but uses another, external DNS resolver on the side.

But which DNS resolver is addressed by Dnsmasq? The answer is not to be found in the Dnsmasq configuration under /etc/dnsmasq as expected at first. A look at the table of running processes reveals that Dnsmasq was started with the -r option:

$ sudo ps -aux

dnsmasq    647  0.0  0.1  11076  1876 ?        S    10:12   0:00 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,

-r stands for --resolv-file and points to a file /run/dnsmasq/resolv.conf which contains the upstream DNS resolvers Dnsmasq should fall back on.

A look into the file reveals that the DNS resolver of our ISP has been entered there. The first line indicates that the file is generated by resolvconf. But how can we put our own default resolver here?

In StackOverflow answers like this it is recommended to put the default nameserver in /etc/resolvconf/resolv.conf.d/head or base. However, on our target this fails - the directory /etc/resolvconf/resolv.conf.d cannot be found.

The reason is that Raspbian “Buster” uses a different resolvconf implementation than newer Linux distributions: openresolv. This does not know a head or base file. Nevertheless it is possible to store one or more default resolvers, which are automatically added to the list of resolvers to be used.

To do this, the configuration file /etc/resolvconf.conf must be edited and a line such as the following must be added:

name_servers="9.9.9.9"

Alternatively for multiple servers e.g.

name_servers="9.9.9.9 1.1.1.1 8.8.8.8"

To apply the changes, Dnsmasq’s resolver file /run/dnsmasq/resolv.conf is regenerated:

sudo resolvconf -u /run/dnsmasq/resolv.conf

A check of the file shows that the default resolver (besides the network specific resolver 10.0.0.1) has been included:

nameserver 9.9.9.9
nameserver 10.0.0.1

In this example, the Quad9 server 9.9.9.9 was included. To check whether this is now actually addressed during a name resolution, the following command can be issued:

(before possibly apt install dnsutils)

nslookup -q=txt -class=chaos id.server.on.quad9.net

The answer should look something like this:

;; Warning: Message parser reports malformed message packet.
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
id.server.on.quad9.net	canonical name = res120.fra.on.quad9.net.

Authoritative answers can be found from:

It is important that the “canonical name” ends with “quad9.net”. If a “SERVFAIL” response is returned instead, something has gone wrong and the DNS resolver is obviously not active.