This article will guide you to enforcing DoT (DNS over TLS) on your running system and at boot time. Support is avaliable in Fedora 42. It will also guide you to set up encrypted DNS for system installation, if you want to try it with current Fedora Rawhide (Fedora 43).
Background
Traditionally, DNS queries are transferred over unencrypted datagrams through UDP port 53. This unencrypted nature provides a potential attack vector when an attacker is able to easily capture and modify DNS requests and responses. This can be mitigated by using encrypted DNS protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH).
Fedora has built in support for DNS over TLS through systemd-resolved, which is the default DNS resolver since Fedora 33. It is also possible to configure enforced or opportunistic DoT via DNSoverTLS option in resolved.conf. However, this only enables DNS encryption for system runtime. This is not enough on Zero Trust Networks where all DNS communication has to be encrypted for system runtime as well as during boot time for network boots and during system installation.
A Red Hat working group was tasked to deliver system-wide support for encrypted DNS that would satisfy the requirements for Zero Trust Networks. The latest bits landed in Fedora 42. (At this time installation support is present only in current Rawhide, future Fedora 43). While the generic idea is similar to what systemd-resolved does – it runs a local caching DNS resolver that accepts local unencrypted queries and forwards them over an encrypted channel to the upstream DNS servers. At this time systemd-resolved remains controversial and there is not much development activity. Therefore, after discussion with systemd developers, we decided to rely on a different service – unbound. However, we do plan to implement support for systemd-resolved in the future and give users a choice.
Enable DoT during system runtime
Encrypted DNS is fully integrated within NetworkManager using its new dnsconfd DNS plugin. This plugin talks to dnsconfd service, which provides a D-Bus API to configure a local DNS resolver. Only unbound is supported at the moment, but more backends will be added in the future. Dedicating the DNS configuration to a standalone service helps NetworkManager focus solely on obtaining the settings. This leaves the peculiarities of individual DNS backends to be dealt with inside dnsconfd.
Install Required Packages
Only the dnsconfd package needs to be installed as NetworkManager is already installed in Fedora by default. This package will also pull in dependencies such as unbound. Make sure to disable systemd-resolved before starting the dnsconfd service to avoid any potential conflict.
$ sudo dnf install dnsconfd
$ sudo systemctl disable --now systemd-resolved && sudo systemctl mask systemd-resolved
$ sudo systemctl enable --now dnsconfd
Configure NetworkManager
The next step is to configure the NetworkManager. The following snippet sets the server to Cloudflare’s 1.1.1.1 and mode to exclusive. This means that this and only this server will be used for all connections.
$ cat /etc/NetworkManager/conf.d/global-dot.conf [main] dns=dnsconfd [global-dns] resolve-mode=exclusive [global-dns-domain-*] servers=dns+tls://1.1.1.1#one.one.one.one $ sudo systemctl restart NetworkManager
Installing custom CA certificate
Some DNS servers require a custom CA certificate bundle which can be installed into the default location /etc/pki/dns/extracted/pem/tls-ca-bundle.pem. Note that the dnsconfd service requires restart as well, if this file is changed.
$ cat /etc/NetworkManager/conf.d/global-dot.conf [main] dns=dnsconfd [global-dns] resolve-mode=exclusive [global-dns-domain-*] servers=dns+tls://10.0.0.100#custom.dns.example $ cat <<EOF > /etc/pki/dns/extracted/pem/tls-ca-bundle.pem ----BEGIN CERTIFICATE----- … custom.dns.example CA certificate -----END CERTIFICATE----- EOF $ sudo systemctl restart dnsconfd $ sudo systemctl restart NetworkManager
Enable DoT during system boot time
In order to enable encrypted DNS during system boot time, it is necessary to configure the initram DNS using specific kernel arguments and install the dnsconfd-dracut package. After this the initram image must be regenerated.
Install Required Packages
# dnf install dnsconfd-dracut
Set kernel arguments
# Select DoT DNS server KERNELARGS="rd.net.dns=dns+tls://1.1.1.1#one.one.one.one" # Only our DoT server will be used for all connections KERNELARGS+=" rd.net.dns-resolve-mode=exclusive" # Use dnsconfd NetworkManager plugin KERNELARGS+=" rd.net.dns-backend=dnsconfd" # Update kernel arguments grubby --args "$KERNELARGS" --update-kernel 0
Regenerate the initram image
The initram image can be regenerated with various tools (like dracut), but simply reinstalling the current kernel package is the simplest solution. It will make certain that dnsconfd and any custom CA certificates are included in the image.
# dnf reinstall kernel-core
However, note that this will regenerate initram only for the latest kernel. If an older kernel is required, it is recommended to call dracut directly and pass the desired kernel in its command line arguments.
# dracut -f --kver="$KERNEL_VERSION"
Enable DoT for system installation
It is possible to enable encrypted DNS during system installation in the current Fedora Rawhide (43). Please make sure that you use the network installation ISO as Live installation media is not yet supported. The only thing that is required is to pass additional kernel arguments to the installer. The installer will take care of everything and encrypted DNS will be configured for the system installation. The configuration will also be installed on the system so it will be automatically set up for the installed system as well as for the boot process. The arguments are the same as described in “Enable DoT during system boot time”, that is:
… rd.net.dns=dns+tls://1.1.1.1#one.one.one.one rd.net.dns-resolve-mode=exclusive rd.net.dns-backend=dnsconfd"
If required, a custom CA certificate bundle can be installed with a new %certificate kickstart directive.
%certificate --dir /etc/pki/dns/extracted/pem/ --filename tls-ca-bundle.pem
-----BEGIN CERTIFICATE-----
... custom CA certificate
-----END CERTIFICATE-----
%end
Enable DoT in FreeIPA
FreeIPA is an open source centralized Identity Management solution that provides its own integrated DNS service. As of Fedora 42, it supports encrypted DNS as well. This is either in a strict mode, where non-encrypted DNS is completely disabled or in a relaxed mode, where both encrypted and non-encrypted protocols are allowed.
For certificate management, Administrators can either provide their own TLS certificates or allow FreeIPA to issue and manage them via its Custodia subsystem. This flexibility enables seamless integration into both enterprise-managed and automated deployments.
Install Required Packages
The integration of DoT into FreeIPA focuses on new deployments and encapsulates the encrypted DNS functionality in dedicated subpackages. These packages are freeipa-client-encrypted-dns and freeipa-server-encrypted-dns. This modular approach ensures that existing installations remain unaffected unless these components are explicitly installed.
$ sudo dnf install freeipa-server-encrypted-dns freeipa-client-encrypted-dns
Fresh installation
To set up FreeIPA with DoT on Fedora, simply install, deploy, and use FreeIPA as usual, but include the relevant encrypted DNS parameters when deploying. This applies to servers, replicas, and clients alike. The new functionality integrates seamlessly into standard installation workflows for new environments.
As mentioned before, administrators can either provide their own TLS certificates or allow FreeIPA to issue and manage them via its Custodia subsystem.
Using your own certificates:
For testing purposes, you can generate certificates using openssl.
$ openssl req -newkey rsa:2048 -nodes -keyout /etc/pki/tls/certs/privkey.pem -x509 -days 36500 -out /etc/pki/tls/certs/certificate.pem -subj "/C=US/ST=NRW/L=Earth/O=CompanyName/OU=IT/CN=master.ipa.test/emailAddress=email@example.com" && chown named:named /etc/pki/tls/certs/privkey.pem /etc/pki/tls/certs/certificate.pem
Use this generated certificate, as shown below, when deploying FreeIPA server by using –dns-over-tls-cert and –dns-over-tls-key, respectively. If these options are empty, a new certificate will be requested from IPA CA.
$ sudo ipa-server-install \ --setup-dns \ --dns-over-tls \ --no-dnssec-validation \ --dot-forwarder "1.1.1.1#one.one.one.one" \ --auto-reverse \ --domain ipa.test \ --realm IPA.TEST \ --hostname master.ipa.test \ --dns-over-tls-cert /etc/pki/tls/certs/certificate.pem \ --dns-over-tls-key /etc/pki/tls/certs/privkey.pem \ -p Secret123 -a Secret123 -U
Existing installations
For existing deployments, administrators must take explicit action to enable DoT. This involves upgrading and installing the required packages (freeipa-client-encrypted-dns and freeipa-server-encrypted-dns). After that the ipa-dns-install commands are issued to include the encrypted DNS options. Care should be taken to evaluate the environment and ensure compatibility before enabling the new functionality.
$ sudo ipa-dns-install --dns-over-tls --dot-forwarder "1.1.1.1#one.one.one.one"
Oscar
“At this time systemd-resolved remains controversial and there is not much development activity” 😱😱😱
Stephan Hegemann
Not much development? Yes. Can’t improve perfection 👍
Steve
for novices – what reading material would you suggest to understand all you have just written about with the goal of:
stopping the bots from reprogramming my system – from scraping mlail accounts to clearly seeing every keystroke made – IE the security of all passwords – banking or on line trading –
Note: I have previously simply notices as enabling auto time/date setting as a penitration window and not enabling causes undating/discovery issues. I have notices the bots setting some update needed flag so that exploits are enabled.
Your advice is appreciated
Anon
The problem with DoT is port 853 – it’s easily identified and can be blocked. I assume the fall back would be regular DNS which is plain text. DoH uses 443 but isn’t system wide, so hard to block without blocking all encrypted traffic, but only with browsers. DNScrypt on the other hand works well in Fedora and you get the best of both worlds – systemwide encryption which is hard to block. I have been using it with Fedora 27 onwards no problem. Far more robust.
Steve
The silence projects volumes of unraveling the perception this type software projects
similar to the business “neck tie”
Yevhen
Didn’t work for me, the DNS stopped working altogether.
Marty
How to do it on atomic desktops?
Pavel Březina
Is there any particular step that failed or is it misbehaving afterwards?
It may be necessary to “systemctl disable –now systemd-resolved && systemctl mask systemd-resolved” to prevent conflicts.
Yevhen
Oh, exactly. It was a conflict between Unbound and systemd-resolved. I seem to have been able to figure it out, but it took a hell of a lot of time, especially for a newbie.
rahul
internet stopped working for me
violetstone
Wait – is Fedora switching away from resolved to Unbound? Or have I misread?
Pavel Březina
No, Fedora is not switching away from resolved. It stays as a default resolver and if it works for you and you don’t care about installation or boot time encrypted DNS, you may keep using it as you are used to.
We have went for unbound only for this particular use case where you need to run encrypted DoT for installation and boot as well. Maybe we should have explained the reasoning behind unbound vs systemd-resolved in the article in more details and better words, but we did not want to focus on it here.
dsp3
The article doesn’t explain where the “Set Kernel Arguments” statements are included. This should be explained IMO.
Pavel Březina
The idea is to call grubby to configure your boot loader. I wrote it as a script for better readability, thought the intention is clear. You can put those lines in your command line to setup the variable and then call grubby with it.
Andrew S
Recommended Fix
Option 1: Use systemd-resolved (Recommended)
[main]
dns=systemd-resolved # Enable integration
Pros: Proper DoT, DNSSEC, caching via systemd-resolved.
Verify:
Option 2: Use dnsconfd (Not Recommended)
[main]
dns=dnsconfd # Bypass systemd-resolved entirely
Only use this if you have a specific reason to avoid systemd-resolved.
Matthew Phillips
I’m hoping eventually Fedora and/or GNOME will support DoH. On my macOS work computer I go to the DNS settings for the WiFi and type in the DoH URL and it just works. Same with iPhone. Just to say it is feasible, of course DoH or not I would rather be using Fedora!
Clive Widdus B.Sc
Why would you design in a single point of failure? “The next step is to configure the NetworkManager. The following snippet sets the server to Cloudflare’s 1.1.1.1 and mode to exclusive. This means that this and only this server will be used for all connections.”
Pavel Březina
You can of course specify multiple servers. For example:
servers=dns+tls://1.1.1.1#one.one.one.one,dns+tls://8.8.8.8#dns.google
Tommyhaf
hi
Stuart Gathman
When querying your own recursive DNS, a vpn works as well – and is transparent to systemd-resolved or any other resolver. We use cjdns (see fedoramagazine article on Cjdns).
The main problem a VPN or DoT/DoH solves is ISPs that block or (worse) intercept plaintext DNS queries – even for business accounts. I understand that they would like to reduce traffic by forcing use of their own servers, but those are often incorrect (e.g. returning ad sites instead of NX_DOMAIN).
There is a different problem: trying to be more private by hiding in a crowd. This is why people pay “VPN” providers that don’t connect your own sites but use NAT to mix your external traffic with lots of other customers in an effort to obscure which IPs you contact from surveillance. For these, you probably want to use the DNS provided by the VPN provider – so that your queries are mixed with lots of others. In this case your queries are already encrypted by going over the VPN to the “privacy” provider.
If you are using DoT/DoH to directly query some DNS provider (e.g. google) expecting more privacy – remember that the DNS provider sees all the queries. I guarantee that google keeps excellent logs. If you don’t want this, you need a DNS provider that promises (with some kind of accountability) “no logs” and other privacy measures. These generally charge for the service.
Andrew S
dnsconfd not re-reading /etc/hosts file