FS#67152 - [networkmanager] NetworkManager & systemd-resloved: DHCP provided DNS server isn't used

Attached to Project: Arch Linux
Opened by François Guerraz (kubrick) - Tuesday, 30 June 2020, 09:06 GMT
Last edited by Toolybird (Toolybird) - Saturday, 03 June 2023, 00:00 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

(originally was a forum post https://bbs.archlinux.org/viewtopic.php?id=256979, but after editing it a few times and adding to it, I realise it's probably a bug)

I am using NetworkManager & systemd-resloved in their default configuration.

/etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf

As it should, NetworkManager reports in the logs when it starts:

dns-mgr[0x55f2a8093240]: init: dns=systemd-resolved rc-manager=symlink, plugin=systemd-resolved

Which is what I want.

NetworkManager correctly picks-up the right DNS server from DHCP

NetworkManager[19709]: <info> [1593431290.2268] dhcp4 (enp0s13f0u3u3): option domain_name_servers => '192.168.199.1'

But it doesn't detect that there is a change with the running configuration:

dns-mgr: (device_ip_config_changed): queueing DNS updates (1)
dns-mgr: (device_ip_config_changed): DNS configuration did not change
dns-mgr: (device_ip_config_changed): no DNS changes to commit (0)

But then, systemd-resolved keeps on using the fallback DNS server:

$ systemd-resolve --status
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 8.8.8.8
Fallback DNS Servers: 1.1.1.1
9.9.9.10
8.8.8.8
2606:4700:4700::1111
2620:fe::10
2001:4860:4860::8888
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 12 (enp0s13f0u3u3)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no

Link 2 (wlp0s20f3)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no

Which https://www.dnsleaktest.com/ confirms.

If I manually set the DNS server for the interface with resolvectl, it works and the correct entries are reported in the status.

This task depends upon

Closed by  Toolybird (Toolybird)
Saturday, 03 June 2023, 00:00 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See comments
Comment by Jan Alexander Steffens (heftig) - Wednesday, 01 July 2020, 20:38 GMT
It works fine for me, so I think this is not a packaging bug.
Comment by François Guerraz (kubrick) - Thursday, 02 July 2020, 12:47 GMT
Correct. This is a third party app messing things up. https://github.com/mullvad/mullvadvpn-app/issues/1885
Comment by Thomas Haller (thom311) - Sunday, 19 July 2020, 11:00 GMT
Btw, `/sbin/NetworkManager --print-config` might be helpful to detect this "issue".

It would show that the configuration from the profiles was overwritten by settings in /var/lib/NetworkManager/NetworkManager-intern.conf.

Loading...