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 WiFi 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
NetworkManager tweaks (optional)
Using iwd
as the WiFi backend
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:
/etc/NetworkManager/conf.d/wifi_backend.conf
[device]
wifi.backend=iwd
Using 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
DNS
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:
ATTENTION: A few notes about setting this up:
- Failure to properly configure
/etc/resolv.conf
will result in broken DNS resolution! - Attempting to symlink
/etc/resolv.conf
whilst insidearch-chroot
will not be possible, since the file is bind-mounted from the archiso live system. In this case, create the symlink from outsidearch-chroot
:ln -sf /run/systemd/resolve/stub-resolv.conf /mnt/etc/resolv.conf
- Some DHCP and VPN clients use the
resolvconf
program to set name server and search domains (see this list). For these, you also need to install thesystemd-resolvconf
package to provide a/usr/bin/resolvconf
symlink.
ln -rsf /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:
- Cloudflare
- Quad9 (without filtering and without DNSSEC)
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.
Set up the fallback addresses 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
systemd-resolved
can be configured to use DNSSEC for validation of DNS requests. It can be configured in three modes:
Setting | Description |
---|---|
allow-downgrade |
Validate DNSSEC only if the upstream DNS server supports it |
true |
Always validate DNSSEC, breaking DNS resolution if the server does not support it |
false |
Disable DNSSEC validation entirely |
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 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:
Setting | Description |
---|---|
opportunistic |
Attempt DNS over TLS when possible and fall back to unencrypted DNS if the server does not support it |
true |
Always use DNS over TLS, breaking resolution if the server does not support it |
false |
Disable DNS over TLS entirely |
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
mDNS
systemd-resolved
is capable of working as a multicast DNS resolver and responder. The resolver provides hostname resolution using a "hostname.local" naming scheme.
mDNS will only be activated for a connection if both systemd-resolved
's mDNS support has been enabled, and if the configuration for the currently active network manager enables mDNS for the connection.
Setting | Description |
---|---|
resolve |
Only enables resolution support, but responding is disabled |
true |
Enables full Multicast DNS responder and resolver support |
false |
Disables both Multicast DNS responder and resolver |
ATTENTION: If you plan on using systemd-resolved
as mDNS resolver and responder consider the following:
- Some desktop environments have the
avahi
package as a dependency. To prevent conflicts,disable
ormask
bothavahi-daemon.service
andavahi-daemon.socket
- If you plan on using a firewall, make sure UDP port
5353
is open
Set up mDNS in a drop-in config file, e.g. /etc/systemd/resolved.conf.d/mdns.conf
:
[Resolve]
MulticastDNS=true
To enable mDNS for a connection managed by NetworkManager tell nmcli
to modify an existing connection:
TIP: The default for all NetworkManager connections can be set by creating a configuration file in /etc/NetworkManager/conf.d/
and setting connection.mdns=2
(equivalent to "yes") in the [connection]
section.
[connection]
connection.mdns=2
nmcli connection modify CONNECTION_NAME connection.mdns yes