- If installing systemd-resolved for the first time, set fallback DNS setting to
True irrespective of the app version.
Tests:
- Ensure that systemd-resolved is not installed. On a fresh systemd without
first setup done, run service.
- Names app setup is run and systemd-resolved is installed if internet
connection is available. Setup succeeds. Fallback DNS setting is true in privacy
app. systemd-resolved has been restarted and current DNS known to Network
Manager has been populated in it. Name resolution works.
- If Internet connection is not available, setup still succeeds but
systemd-resolved package is not installed.
- Rerun setup without internet connectivity. Setup succeeds without installing
systemd-resolved.
- Rerun setup with internet connectivity. Setup succeeds and installs
systemd-resolved. Fallback DNS setting is true in privacy app. systemd-resolved
has been restarted and current DNS known to Network Manager has been populated
in it. Name resolution works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Config app description is as expected.
- Config form does not show domain name field anymore.
- Submitting the form with changes works.
- Names app has correct link for configuring static domain name. Clicking it
takes to page for setting domain name.
- On startup, static domian name signal is sent properly if set. Otherwise no
signal is send.
- Change domain name form shows correct value for current domain name.
- Change domain name form sets the value for domain name properly.
- Page title is correct.
- Validations works.
- Add/remove domain name signals are sent properly.
- Success message as shown expected
- /etc/hosts is updated as expected.
- Unit tests work.
- Functional tests on ejabberd, letsencrypt, matrix, email, jsxc, openvpn
- After freshly starting the service. Visiting names app shows correct list of
domains.
- ejabberd:
- Installs works as expected. Currently set domain_name is setup properly.
Copy certificate happens on proper domain.
- Changing the domain sets the domain properly in ejabberd configuration.
- Ejabberd app page shows link to name services instead of config app.
Clicking works as expected.
- letsencrypt:
- When no domains are configured, the link to 'Configure domains' is to the
names app.
- matrix-synapse:
- Domain name is properly shown in the status.
- email:
- Primary domain name is shows properly in the app page.
- Setting new primary domain works.
- When installing, domain set as static domain name is prioritized as primary
domain.
- jsxc:
- Show the current static domain name in the domain field. BOSH server is
available.
- openvpn:
- Show the current static domain in profile is set otherwise show the current
hostname.
- If domain name is not set, downloaded OpenVPN profile shows hostname.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Config app description is as expected.
- Config form does not show hostname anymore.
- Submitting the form with changes works.
- Names app has correct link for configuring Local Domain Name. Clicking it
takes to page for setting hostname.
- Avahi shows the current .local domain correctly in Names app.
- Change hostname form shows correct value for current hostname.
- Change hostname form sets the value for hostname properly.
- Page title is correct.
- Validations works.
- Pre/post hostname change signals are sent properly
- Success message as shown expected
- hostnamectl shows the set domain
- If domain name is not set, downloaded OpenVPN profile shows hostname.
- Unit tests work.
- Functional tests on names/config/avahi apps work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Reloading systemd-resolved does not seem to apply the DNS-over-TLS changes
fully. Although resolvectl shows the new status after a reload, systemd-resolved
seems to be using incorrect DNS-over-TLS setting.
Tests:
- Without the patch, set DNS server that does not support DNS-over-TLS such as
dnsmasq in Network Manager's 'shared' connection. Then enable DNS-over-TLS.
resolvectl shows that DNSOverTLS flag correctly. But name resolutions still
work.
- With the patch, repeat the above and notice that resolution does not work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Visit the names app. New 'Domains' heading and configuration section appear.
- DNS-over-TLS configuration option is as expected.
- When the configuration file does not exist, the option selected is 'no'.
- When the configuration option is changed, 'resolvectl' shows the newly set
configuration. Using 'resolvectl query {domain}' does not work when DoT is on
and server does not support DoT. 'opportunistic' and 'no' work on those cases.
- When a DNS server supporting DoT (such as 1.1.1.1) is manually set, resolution
with all three settings works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Disable mDNS resolution. While we can migrate our DNS-SD service definition
files to systemd-resolved and switch from using avahi to systemd-resolved, many
programs still solely depend on avahi-daemon. Examples include cups and GNOME.
It is not clear if they will work any mDNS daemon or if they interact with
avahi-daemon in other ways that the mDNS protocol. So, for now, disable mDNS in
systemd-resolved and continue to use avahi-daemon for it. This is also Fedora's
default.
- Re-introduce Fallback DNS servers with the value same as the upstream systemd
project. Debian removes the default fallback DNS servers likely because they
could be considered a privacy violation. However, when systemd-resolved package
is first installed, the post install script recommends a reboot instead of
feeding the currently configured nameservers from /etc/resolve.conf into
systemd-resolved. Immediately, this causes the system not be able to connect to
any external servers. While this may be acceptable solution for interactive
systems and pre-built images, FreedomBox has to a) be available for remote
access b) perform upgrades without user intervention (and without reboot until a
day). To mitigate privacy concerns, an option to disable these fallback servers
will be provided in the UI.
- systemd-resolved's stub resolver runs on 127.0.0.53%lo:53 and 127.0.0.54. This
does not conflict either with shared connections which listen on 10.42.x.1 or
with bind which listens on 127.0.0.1 (and other IP addresses). This MR does not
address the existing conflict between bind and shared network connections.
However, it does not cause any further conflicts.
Tests:
* mDNS
- Avahi diagnostics works. daemon is running. mdns port is exposed in the
firewall.
- systemd-resolved does not listen on mDNS ports.
- Running avahi-browse shows freedombox on local network.
- Running avahi-browse shows the services ssh, sftp-ssh, http and ejabberd.
- Machine can be discovered in Gnome Files.
* NetworkManager shared connections
- After install/upgrade to systemd-resolved, 'shared' connections can be
created.
- With a 'shared' connection configured and active, it is possible to upgrade to
using systemd-resolved.
- Resolving domains from a machine on shared network goes via systemd-resolved
on FreedomBox.
* Bind
- Installing, running tests on bind works.
- Programs connecting from outside network can connect to bind as expected.
- Programs connecting from local machine can connect to bind as expected.
* Upgrading works
- Upgrading to new FreedomBox package works
- systemd-resolved is installed and running. 'resolvectl' shows a proper name
server (or fallback nameserver like 1.1.1.1).
- libnss-resolve is installed and configured in /etc/nsswitch.conf
- /etc/resolv.conf has proper link to /run/systemd/resolve/stub-resolv.conf.
- Programs using /etc/resolv.conf directly work. Install python3-pycares.
python3 -m pycares freedombox.org.
- NetworkManager has passed on proper DNS entries. In logs dns=systemd-resolved,
rc-manager=unmanaged, plugin=systemd-resolved
- DNS resolution works after first setup. Installing packages works.
- 'resolvectl query' resolution works.
- Programs using glibc API resolution such as 'ping' work.
* Fresh image
- Building an image with new freedombox package works without error.
- Booting from fresh images works.
- systemd-resolved is installed and running. 'resolvectl' show proper name
server.
- libnss-resolve is installed and configured in /etc/nsswitch.conf
- /etc/resolv.conf has proper link to /run/systemd/resolve/stub-resolv.conf
- Programs using /etc/resolv.conf directly work. Install python3-pycares.
python3 -m pycares wikipedia.org
- NetworkManager has passed on proper DNS entries. In logs dns=systemd-resolved,
rc-manager=unmanaged, plugin=systemd-resolved
- DNS resolution works after first setup. Installing packages works.
* Installing package on Debian
- Installing new freedombox package in Debian machine works.
- systemd-resolved is installed and running.
- libnss-resolve is installed and configured.
- /etc/resolv.conf has proper link to /run
- NetworkManager has passed on proper DNS entries to systemd-resolved using
'nmcli reload dns-rc'.
- Resolution works with fallback DNS servers when network interfaces are
configured with /etc/network/interfaces
* OpenVPNs works
- As a server, we don't push DNS servers to the client. So, a client continues
to use its old DNS servers. With systemd-resolved running on server, the client
is able to connect to OpenVPN server, route traffic to the internet, and resolve
DNS queries.
* WireGuard works
- As a server, we can't push DNS servers to the client. So, a client continues
to use its old DNS servers. With systemd-resolved running on server, the client
is able to connect to WireGuard server, route traffic to the internet, and
resolve DNS queries.
- As a client, server does not push DNS servers to the client. So, a client
continues to use its old DNS servers. With systemd-resolved running on the
client, the client is able to connect to WireGuard server, route traffic to the
internet, and resolve DNS queries.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
