Package resolvconf=1.79ubuntu10.18.04.1 broken

Can confirm. Specifically breaks DNS resolution in Firefox when I'm logged into an OpenConnect VPN. I can resolve hosts that are in public DNS, but I'm uncertain if this is because of caching. Internal DNS over the VPN no longer resolves. Downgrading to the previous version of resolvconf restores functionality.

Status changed to 'Confirmed' because the bug affects multiple users.

For the affected, a workaround is available:
Download and manually install resolveconf from the previous version-1.79ubuntu10

No vpn - DNS resolver broken by update (on production server)

bug@test:~$ 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.

nameserver 127.0.0.53
search ~~cut~~.intern lxd
options edns0

### ----------

bug@test:~$ systemd-resolve --status
Global
         DNS Servers: 10.176.0.1
                      10.176.0.2
                      10.168.127.126
          DNS Domain: ~~cut~~.intern
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
~~ cut ~~

Link 3 (lxdbr0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.145.28.1
          DNS Domain: lxd

### ----------

bug@test:~$ lxc launch ubuntu:18.04 ub18-1
Creating ub18-1
Starting ub18-1

### ----------

bug@test:~$ dig ub18-1.lxd
;; ANSWER SECTION:
ub18-1.lxd. 600 IN A 10.145.28.214
;; SERVER: 127.0.0.53#53(127.0.0.53)

### ----------

bug@test:~$ sudo apt-get upgrade
The following packages will be upgraded:
  resolvconf
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Preparing to unpack .../resolvconf_1.79ubuntu10.18.04.1_all.deb ...
Processing triggers for resolvconf (1.79ubuntu10.18.04.1) ...

### ----------

bug@test:~$ 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.

nameserver 10.176.0.1
nameserver 10.176.0.2
nameserver 10.168.127.126
search ~~cut~~.intern lxd

### ----------

bug@test:~$ dig ub18-1.lxd
;; QUESTION SECTION:
;ub18-1.lxd. IN A
;; SERVER: 10.176.0.1#53(10.176.0.1)

### ----------

# temporary fix:

bug@test:~$ wget http://de.archive.ubuntu.com/ubuntu/pool/universe/r/resolvconf/resolvconf_1.79ubuntu10_all.deb
bug@test:~$ sudo dpkg --install resolvconf_1.79ubuntu10_all.deb
bug@test:~$ dig ub18-1.lxd
;; ANSWER SECTION:
ub18-1.lxd. 600 IN A 10.145.28.214

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

@bruno-42 are you upstream nameservers not reachable from your system?

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.

Hello Boris, or anyone else affected,

Accepted resolvconf into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.10.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Boris, or anyone else affected,

Accepted resolvconf into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

@ddstreet:
> are you upstream nameservers not reachable from your system?
upstream servers have no clue about local LXC/LXD (linuxcontainers.org) DNS names.
Configuration basically done via

systemd-resolve --interface lxdbr0 --set-dns 10.145.28.1 --set-domain lxd

This gets broken by the update....

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.10.2

---------------
resolvconf (1.79ubuntu10.18.10.2) cosmic; urgency=medium

  * Revert the previous SRU, which regressed DNS handling in certain
    configurations. LP: #1819625.

 -- Steve Langasek <email address hidden> Wed, 13 Mar 2019 14:15:36 -0700

I had troubles with DNS resolution in last days after reboot and I think it may be related to resolvconf package update. I spotted following entries in resolvconf-pull-resolved.service journal:

mar 14 09:30:01 *** systemd[1]: resolvconf-pull-resolved.service: Start request repeated too quickly.
mar 14 09:30:01 *** systemd[1]: resolvconf-pull-resolved.service: Failed with result 'start-limit-hit'.
mar 14 09:30:01 *** systemd[1]: Failed to start resolvconf-pull-resolved.service.

Because of that DNS resolution was not working after boot but I used workaround of disabling and enabling Wifi from GUI. I guess resolvconf-pull-resolved.service was started too many times right after booting the system.
For now I just uninstalled resolvconf package and it should fix it but I hope my message can help to track the problem.

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.04.2

---------------
resolvconf (1.79ubuntu10.18.04.2) bionic; urgency=medium

  * Revert the previous SRU, which regressed DNS handling in certain
    configurations. LP: #1819625.

 -- Steve Langasek <email address hidden> Wed, 13 Mar 2019 14:15:36 -0700

I'm experiencing this issue with Ubuntu 19.04

resolvconf version: 1.79ubuntu13

Oct 6 21:30:19 miranda systemd[1]: Failed to start resolvconf-pull-resolved.service.
Oct 6 21:30:19 miranda systemd[1]: resolvconf-pull-resolved.service: Start request repeated too quickly.
Oct 6 21:30:19 miranda systemd[1]: resolvconf-pull-resolved.service: Failed with result 'start-limit-hit'.