Comment 6 for bug 1819625

On a desktop system continuously upgraded from pre-xenial (through non-LTS releases), I have the following before upgrade:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 27 Mar 29 2012 /etc/resolv.conf -> /run/resolvconf/resolv.conf
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
domain $mydom
search $mysearch
nameserver 127.0.0.53
search $mysearch buildd enablement external internal
options edns0
$

After upgrade:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
domain $mydom
search $mysearch
nameserver 10.172.64.1
nameserver 75.75.75.75
nameserver 75.75.76.76
search $mysearch buildd enablement external internal
$

This is evidently what the SRU is intended to do, but the problem is that it regresses systems that have split DNS (e.g. my 10.172.64.1 nameserver is on a VPN, which is NOT where I want my DNS to go by default and it should NOT be treated round-robin with the other DNS servers), and have the resolvconf package installed.

In practice, I noticed this problem because my VPN connection dropped but systemd-resolved + resolvconf didn't get the message, and all DNS requests were going to an unreachable DNS server. But the underlying behavior is still wrong per se, and one of the things that systemd-resolved was introduced to address.

We can't trade one DNS misbehavior for another in SRU. I will be reverting this SRU.

The right solution is to fix systems to that they ALWAYS point to 127.0.0.53 as their local resolver.