After upgrade to 19.10, DNS server isn't configured by DHCP client

I have encountered a problem with DHCP after upgrading a virtual machine from ubuntu 19.04 to 19.10. The problem is that the VM no longer seems to configure the DNS server using its DHCP client. It does configure the gateway and IP address correctly however.

The details of my local network are that the gateway is 10.3.7.12 and the DNS server is 10.3.7.14. This latter machine is also the host of the VM and the DHCP server (running dnsmasq). It uses bridged networking, so the VM should be just another machine on the LAN. Other VMs, and other devices with DHCP clients, work correctly, as did this VM before upgrading ubuntu to 19.10.

Anyway, after starting the VM, "netstat -rn" shows :-

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.3.7.12 0.0.0.0 UG 0 0 0 enp0s3
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 enp0s3

which looks correct. "hostname -I" gives "10.6.0.184", which also is what I would expect.

I can ping numeric addresses, but hostname lookups always fail.

"/etc/resolv.conf" contains :-

# 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

Running "systemd-resolve --status" gives :-

Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (enp0s3)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Poking around a bit I found that there is a file "/var/lib/dhcp/dhclient.enp0s3.leases", with a timestamp corresponding to the boot time, which contains :-

default-duid "\000\001\000\001%;tt\010\000'\233\302L";
lease {
  interface "enp0s3";
  fixed-address 10.6.0.184;
  option subnet-mask 255.0.0.0;
  option routers 10.3.7.12;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 10.3.7.14;
  option dhcp-server-identifier 10.3.7.14;
  option domain-search "poges.";
  option dhcp-renewal-time 1800;
  option broadcast-address 10.255.255.255;
  option dhcp-rebinding-time 3150;
  option host-name "vblinux1";
  option domain-name "poges";
  renew 3 2019/10/30 13:58:25;
  rebind 3 2019/10/30 13:58:25;
  expire 3 2019/10/30 13:58:25;
}
lease {
  interface "enp0s3";
  fixed-address 10.6.0.184;
  option subnet-mask 255.0.0.0;
  option routers 10.3.7.12;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 10.3.7.14;
  option dhcp-server-identifier 10.3.7.14;
  option domain-search "poges.";
  option dhcp-renewal-time 1800;
  option broadcast-address 10.255.255.255;
  option dhcp-rebinding-time 3150;
  option host-name "vblinux1";
  option domain-name "poges";
  renew 3 2019/10/30 14:22:56;
  rebind 3 2019/10/30 14:51:20;
  expire 3 2019/10/30 14:58:50;
}

and "/run/systemd/resolved.conf.d/isc-dhcp-v4-enp0s3.conf" contains :-

[Resolve]
DNS=10.3.7.14
Domains=poges. poges

("poges" is just the local pretend domain name).

Eventually I found a rather unsatisfactory workaround, which is to edit "/etc/systemd/resolved.conf" and uncomment and change the following two lines :-

FallbackDNS=10.3.7.14
Domains=poges. poges

After rebooting, hostname lookups work correctly again. "/etc/resolv.conf" contains a "search poges" line, and "systemd-resolve --status" includes the correct entries ("Current DNS Server" and "DNS Domain").

But this workaround surely shouldn't be necessary, and it "hardwires" these values, which is obviously undesirable.