Here is my use case experience, after running a clean install of Kubuntu
17.10.
Initially everything was perfect, and for at least 10 days my machine
booted perfectly fine and DNS working without issue.
However, after installing virt manage Virtual Machine Manager, like so
sudo apt-get install qemu-system qemu-kvm virt-manager wireshark
I configured some additional Virbr networks ( see below ) The following
day after a reboot, I had no DNS resolution, I hacked /etc/resolv.conf
to add a nameserver. All good until reboot, and then back to square one.
Once I discovered this bug things became clearer, and I have applied fix
at post #8 above
I figure that my use of virt-manager might be an interesting edge case
that break things with systemd-resolve. Below is the output from status,
which highlights the issue, there are no DNS servers listed.
Hope this info is useful
ricktimmis@ricktimmis-Latitude-E6430:~$ systemd-resolve --status
Global
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 23 (vnet1)
Current Scopes: LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 17 (vnet0)
Current Scopes: LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 15 (vnet5)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 14 (vnet4)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 13 (vnet3)
Current Scopes: LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 9 (virbr0-nic)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 8 (virbr0)
Current Scopes: LLMNR/IPv4
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 7 (virbr1-nic)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 6 (virbr1)
Current Scopes: LLMNR/IPv4
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 5 (br0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (eth1)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wlan0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (eth0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1624320
Title:
systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
entries
Status in systemd package in Ubuntu:
Confirmed
Bug description:
systemd-resolved, or more precisely the hook script
/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf, causes
resolvconf to add 127.0.0.53 to the set of nameservers in
/etc/resolv.conf alongside the other nameservers. That makes no sense
because systemd-resolved sets up 127.0.0.53 as a proxy for those other
nameservers. The effect is similar to bug 1624071 but for
applications doing their own DNS lookups. It breaks any DNSSEC
validation that systemd-resolved tries to do; applications will
failover to the other nameservers, bypassing validation failures. And
it makes failing queries take twice as long.
/etc/resolv.conf should have only 127.0.0.53 when systemd-resolved is
active.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
