Network

Set up the default host name of the machine as well as localhost:

NOTE: sebin-desktop is used as an example here. Set $HOSTNAME to whatever you like.

# Define an environment variable containing the desired hostname
export HOSTNAME='sebin-desktop'

# Set the hostname of the machine
echo "$HOSTNAME" > /etc/hostname

# Set localhost to resolve to the machine's loopback address
echo "127.0.0.1	localhost" >> /etc/hosts
echo "::1		localhost" >> /etc/hosts
echo "127.0.1.1	$HOSTNAME.localdomain	$HOSTNAME" >> /etc/hosts

Set wireless region

If your machine has Wi-Fi it is advisable to set the region for wireless radio waves to comply with local regulations:

# Install crda
pacman -S iw

# Set the wireless region, e.g. Germany
iw reg set DE

Network manager

Previously we installed NetworkManager as our default network mangaging software. GNOME and KDE have out of the box support for managing network connections in their settings dialogs in a graphical manner. Both rely on NetworkManager.

Enable NetworkManager to start at boot:

systemctl enable NetworkManager

Using iwd as the Wi-Fi backend (optional)

By default NetworkManager uses wpa_supplicant for managing Wi-Fi connections.

iwd (iNet wireless daemon) is a wireless daemon for Linux written by Intel. The core goal of the project is to optimize resource utilization by not depending on any external libraries and instead utilizing features provided by the Linux Kernel to the maximum extent possible.

To enable the experimental iwd backend, first install iwd and then create the following configuration file:

mkdir /etc/NetworkManager/conf.d
nano /etc/NetworkManager/conf.d/wifi_backend.conf

With the following contents:

[device]
wifi.backend=iwd

systemd-resolved for DNS name resolution

systemd-resolved is a systemd service that provides network name resolution to local applications via a D-Bus interface, the resolve NSS service, and a local DNS stub listener on 127.0.0.53.

Benefits of using systemd-resolved include:

• resolvectl as the primary single command for interfacing with the network name resolver service
• A system-wide DNS cache for speeding up subsequent name resolution requests
• Split DNS when using VPNs, which can help in preventing DNS leaks when connecting to multiple VPNs (See Fedora Wiki for a detailed explenation why this is important)
• Integrated DNSSEC capabilities to verify the authenticity and integrity of name resolution requests, e.g. to prevent cache poisoning/DNS hijacking
• DNS over TLS for further securing name resolution requests by encrypting them, improving privacy (not to be confused with DNS over HTTPS)

To use systemd-resolved enable the respective unit:

systemctl enable systemd-resolved

To provide domain name resolution for software that reads /etc/resolv.conf directly, such as web browsers and GnuPG, systemd-resolved has four different modes for handling the file

• stub
• static
• uplink
• foreign

The recommende mode is stub, which uses /run/systemd/resolve/stub-resolv.conf, and contains the local stub 127.0.0.53 as the only DNS server and a list of search domains.

This propagates the systemd-resolved managed configuration to all clients. To use it, replace /etc/resolv.conf with a symbolic link to it:

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

When set up this way, NetworkManager automatically picks up systemd-resolved for network name resolution.

Fallback DNS servers

If systemd-resolved does not receive DNS server addresses from the network manager and no DNS servers are configured manually then systemd-resolved falls back to the fallback DNS addresses to ensure that DNS resolution always works.

The fallback order is:

1. Cloudflare
2. Quad9 (without filtering and without DNSSEC)
3. Google

ATTENTION: Depending on your use-case, you might not want to route all your DNS traffic through the pre-determined fallback servers for privacy reasons. Do your own research on fallback DNS servers that you want to trust.

Fallback addresses can be manually set in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/fallback_dns.conf:

[Resolve]
FallbackDNS=127.0.0.1 ::1

To disable the fallback DNS functionality set the FallbackDNS option without specifying any addresses:

[Resolve]
FallbackDNS=

DNSSEC

WARNING: DNSSEC support in systemd-resolved is considered experimental and incomplete.

DNSSEC is a suite of extensions to the DNS system. Benefits of utilizing DNSSEC include authentication and data integrity, but not encryption. For actually encrypting your DNS traffic, see the section below.

systemd-resolved can be configured to use DNSSEC for validation of DNS requests. It can be configured in three modes:

Set up DNSSEC in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/dnssec.conf:

[Resolve]
DNSSEC=allow-downgrade

DNS over TLS

DNS over TLS is a security protocol for encrypting DNS queries and responses via Transport Layer Security (TLS), thereby increasing privacy and security by preventing eavesdropping and manipulation of DNS requests in man-in-the-middle attack scenarios.

DNS over TLS in systemd-resolved is disabled by default. To enable validation of your DNS provider's server certificate, include their hostname in the DNS setting in the format ip_address#hostname and set DNSOverTLS to one of three modes:

ATTENTION: When setting DNSOverTLS=opportunistic systemd-resolved will try to use DNS over TLS and if the server does not support it fall back to regular DNS. Note, however, that this opens you to "downgrade" attacks, where an attacker might be able to trigger a downgrade to non-encrypted mode by synthesizinig a response that suggests DNS over TLS was not supported.

WARNING: If setting DNSOverTLS=yes and the server provided in DNS= does not support DNS over TLS all DNS requests will fail!

Set up DNS over TLS in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/dns_over_tls.conf:

[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net [2620:fe::fe]#dns.quad9.net [2620:fe::9]#dns.quad9.net
DNSOverTLS=yes

Multicast DNS

systemd-resolved is capable of working as a multicast DNS (mDNS) resolver and responder. The resolver provides hostname resolution using a "hostname.local" naming scheme.

mDNS support in systemd-resolved is enabled by default. For a given connection, mDNS will only be activated if both mDNS in systemd-resolved is enabled, and if the configuration for the currently active network manager enables mDNS for the connection.

The MulticastDNS setting in systemd-resolved can be set to one of the following:

To enable mDNS for a connection managed by NetworkManager tell nmcli to modify an existing connection:

nmcli connection modify CONNECTION_NAME connection.mdns yes

[connection]
connection.mdns=2

Avahi

Avahi implements zero-configuration networking (zeroconf), allowing for multicast DNS/DNS-SD service discovery. This enables programs to publish and discover services and hosts running on a local network, e.g. network file sharing servers, remote audio devices, network printers, etc.

Some desktop environments pull in the avahi package as a dependency. It enables their file manager to scan the network for services and make them easily accessible.

Avahi provides local hostname resolution using a "hostname.local" naming scheme. To use it, install the avahi and nss-mdns package and enable Avahi:

pacman -S avahi nss-mdns
systemctl enable avahi-daemon

Then, edit the file /etc/nsswitch.conf and change the hosts line to include mdns_minimal [NOTFOUND=return] before resolve and dns:

hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns

To discover services running in your local network:

avahi-browse --all --ignore-local --resolve --terminate

To query a specific host for the services it advertises:

avahi-resolve-host-name hostname.local

Avahi also includes the avahi-discover graphical utility that lists the various services on your network.