Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 freswa (frederik) - Wednesday, 01 July 2020, 20:30 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
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 0%
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

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...