Ubuntu – DNS set to systemd’s 127.0.0.53 – how to change permanently

dnssystemd-resolved

I've recently upgraded to 17.10. When I try to browse to a website, or ping a domain it fails saying the site cannot be resolved.

network-admin shows the contents of /etc/resolv.conf to be nameserver: 127.0.0.53

If I change that to 8.8.8.8 or 208.67.222.222 then everything works. Until I reboot.

Upon reboot or resume, the nameserver is reset to 127.0.0.53.

How do I permanently set the nameserver to something that works?

For systemd fans, if I run systemd-resolve --status I get

Link 3 (wlo1)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no


If I follow the advice at this question – DNS keeps resetting after reboot. Ubuntu 17.10 – DNS still fails to resolve.

• You can install a package resolvconf, which will modify the way /etc/resolv.conf is built up at system boot.

sudo apt install resolvconf


You can then create or modify a file /etc/resolvconf/resolv.conf.d/tail. If you put in this file a line nameserver 8.8.8.8, this line will be added at the end of /run/resolvconf/resolv.conf at boot. /etc/resolv.conf will now be a symbolic link to this file.

Post Scriptum:

Almost two years after posting my answer I came across https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1778946 which explains exactly why merely installing resolvconf solved a dns problem I had at the time. I feel I have to share this here.

Although my answer addresses the question in a proper way, indeed a warning should be added that, if you want/need to do this, probably something else is wrong. This was already stated by @intelfx at the time, 127.0.0.53 should work by itself.

According that bug report, after a pptp VPN goes down, resolv.conf is restored with the wrong access rights. ping ubuntu.com does not work, sudo ping ubuntu.com does. Installing resolvconf solved it, because it takes over resolv.conf, restoring it with correct rights. Changing systemd-resolve settings is no solution in this case, since the bug is in ppp. But an alternative, maybe simpler solution is sudo chmod a+r /etc/resolv.conf after VPN down. And this can be automated by putting an executable script in /etc/NetworkManager/dispatcher.d with contents:

#!/bin/sh
if [[ "$1"="ppp0" && "$2"="vpn-down" ]]; then
/bin/chmod a+r /etc/resolv.conf
fi


In all cases the contents of resolv.conf do not change. And, yes, I know pptp must be avoided because of security issues, but at the time I thought of it as a good excercise for an ubuntu newbie. I imagined it would work out of the box. Little did I know that it would give me a headache, as diagnosed so well by @intelfx.