Score:1

Setting global DNS + MAC address settings on a Debian-based Linux distribution with systemd-resolved + NetworkManager

in flag

I'm running a Debian-based Linux distribution, specifically Pop!_OS 22.04 (Ubuntu jammy). I'd like to set custom DNS + MAC address settings globally - that is, to be applied to all network connections automatically, new and pre-existing.

Specifically, I'd like to change the following settings:

  • Enable DNSSEC
  • Enable DNS-over-TLS
  • Change my DNS servers to AdGuard DNS
  • Enable MAC address randomization

Currently, I've created three files that should make these changes.

/etc/systemd/resolved.conf.d/dns.conf:

DNSSEC=allow-downgrade
DNSOverTLS=opportunistic

/etc/NetworkManager/dns.conf:

# specify dns servers
# ignore dhcp-provided

[ipv4]
dns=94.140.14.14;94.140.15.15;
ignore-auto-dns=true

[ipv6]
dns=2a10:50c0::ad1:ff;2a10:50c0::ad2:ff;
ignore-auto-dns=true

/etc/NetworkManager/mac.conf:

[device]
# randomize mac address when scanning for wifi networks
wifi.scan-rand-mac-address=yes

[connection]
# randomize mac address upon initial network connection
# retain generated mac address for all future reconnections
# (per-network)
ethernet.cloned-mac-address=stable
wifi.cloned-mac-address=stable

After creating these files and issuing a reboot, there's no indication that any changes regarding the network connection have been made.

AdGuard's test page shows that its DNS is "Not Running".

$ nmcli dev show wlp0s20f3 (Wi-Fi card):

GENERAL.DEVICE:                         wlp0s20f3
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         C6:F5:1A:8E:84:4D
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     NotYourWiFi
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveC>
IP4.ADDRESS[1]:                         192.168.0.153/24
IP4.GATEWAY:                            192.168.0.1
IP4.ROUTE[1]:                           dst = 192.168.0.0/24, nh = 0.0.0.0, mt >
IP4.ROUTE[2]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt >
IP4.ROUTE[3]:                           dst = 0.0.0.0/0, nh = 192.168.0.1, mt =>
IP4.DNS[1]:                             192.168.0.1
IP4.DOMAIN[1]:                          mbfamily.localdomain
IP6.ADDRESS[1]:                         fe80::70e0:14db:aeb6:b6be/64
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = fe80::/64, nh = ::, mt = 1024

$ resolvectl status:

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s31f6)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp0s20f3)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1
       DNS Servers: 192.168.0.1
        DNS Domain: mbfamily.localdomain

/etc/resolv.conf:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search mbfamily.localdomain

/run/systemd/resolve/resolv.conf:

# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.0.1
search mbfamily.localdomain

$ systemd-analyze cat-config systemd/resolved.conf shows that resolved.conf.d/dns.conf is being read, however:

# /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full co>
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4>
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.go>
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#d>
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

# /etc/systemd/resolved.conf.d/dns.conf
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
paladin avatar
id flag
ResolveD priorizes DNS settings from the interfaces, when not explicit deactivated. How about you setup the global DNS via `resolved.conf` instead of using NetworkManager.
unilock avatar
in flag
@paladin The `DNSSEC` and `DNSOverTLS` settings, while read by `systemd` (as reported by `systemd-analyze`), were apparently not applied correctly, as reported by `resolvectl` and `nmcli dev show`. So I don't believe editing `resolved`'s configs would help here. Regardless, I don't believe `systemd-resolved` allows for MAC randomization.
paladin avatar
id flag
What has a resolver to do with MAC randomization?
unilock avatar
in flag
@paladin I want to enable MAC randomization, as I said in my original post. It seems you can't do that with `systemd-resolved`. So using that alone would not work.
paladin avatar
id flag
I just noticed that your `wlp0s20f3` uses LLMNR, probably because your NetworkManager is wrongly configured. I'll repeat my other question, what has a resolver to do with MAC randomization? I would guess, nothing. PS I use systemd-networkd for network configuration.
unilock avatar
in flag
@paladin NetworkManager's configuration has been untouched aside from the modifications I've already mentioned, though it's possible Pop!_OS's default configuration could be faulty. As for your question, I assume a resolver has nothing to do with MAC randomization. I'm not sure why you're asking this.
Score:0
id flag

This is my systemd-resolved config for DNSSEC and this works.

/etc/systemd/resolved.conf

DNS=9.9.9.9#dns9.quad9.net 2620:fe::fe#dns9.quad9.net 2620:fe::9#dns9.quad9.net
FallbackDNS=149.112.112.112#rpz-public-resolver1.rrdns.pch.net
Domains=home.arpa
DNSSEC=yes
DNSOverTLS=yes
MulticastDNS=no
LLMNR=no
Cache=yes
DNSStubListener=yes
ReadEtcHosts=yes
ResolveUnicastSingleLabel=no

it's especially important that the following options are deactivated, like so:

MulticastDNS=no
LLMNR=no

You need to use the stub-resolver from systemd-resolved or the systemd-socket for this to work.

cd /etc/ && ln -sf /run/systemd/resolve/stub-resolv.conf resolv.conf

unilock avatar
in flag
`MulticastDNS` and `LLMNR` default to `no`, at least on my system. Also, `/etc/resolv.conf` is already symlinked to `run/systemd/resolve/stub-resolv.conf`, as seen in my original post. In any case, using the exact values you provided for `DNS` and `FallbackDNS` didn't change anything.
unilock avatar
in flag
OK, it seems that `LLMNR` does *not* default to `no`; I assumed the commented values in `/etc/systemd/resolved.conf` were the defaults. Though I'm not sure where it's being changed to `yes`, in terms of a conf file.
paladin avatar
id flag
@unilock Default values are compiled into the program/libraries. You would need to read the source code for double checking. Original Debian usually defaults LLMNR and MulticastDNS values to `yes`.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.