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
$ 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
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
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:
Alternatively for multiple servers e.g.
name_servers="18.104.22.168 22.214.171.124 126.96.36.199"
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 188.8.131.52 nameserver 10.0.0.1
In this example, the Quad9 server 184.108.40.206 was included. To check whether this is now actually addressed during a name resolution, the following command can be issued:
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.