Modern network privacy requires robust protection against cleartext DNS surveillance and spoofing attacks. By default, legacy DNS queries transmit over UDP port 53 without cryptographic protection, allowing local network snoops, public Wi-Fi operators, and intermediate internet service providers to inspect every domain destination request. In Ubuntu, systemd-resolved provides built-in, native support for DNS over TLS (DoT), encrypting client lookup traffic over TLS port 853 without requiring bulky third-party proxy daemons.
Understanding systemd-resolved DNS Over TLS Architecture
DNS over TLS wraps standard DNS requests inside Transport Layer Security sessions over dedicated TCP port 853. Within modern Ubuntu installations (such as Ubuntu 22.04 LTS and 24.04 LTS), systemd-resolved operates as a local caching resolver listening on stub loopback address 127.0.0.53:53. Applications and system tools route lookups locally to this stub listener, which then negotiates upstream TLS sessions with configured cryptographic DNS providers (such as Cloudflare 1.1.1.1, Quad9 9.9.9.9, or custom enterprise resolvers).
The service supports two operating modes for DoT encryption:
- opportunistic: Attempts TLS handshake negotiation first; if the upstream server fails or does not support TLS port 853, lookups silently fall back to unencrypted UDP port 53.
- yes (strict enforcement): Mandates that all upstream DNS exchanges succeed across authenticated TLS connections. If TLS negotiation fails or times out, the query drops, preventing silent unencrypted fallbacks.
Configuring Upstream Resolvers and DoT in resolved.conf
System-wide resolver parameters reside in /etc/systemd/resolved.conf or drop-in configuration snippets placed under /etc/systemd/resolved.conf.d/. Using drop-in configuration snippets ensures updates to standard package files do not overwrite customized network encryption settings.
Create a dedicated configuration drop-in file using your preferred terminal text editor:
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo nano /etc/systemd/resolved.conf.d/dot.conf
Add the following configuration directives specifying upstream TLS-capable DNS servers and strict TLS enforcement:
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
FallbackDNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes
DNSSEC=allow-downgrade
Cache=yes
Notice the inclusion of the server identity suffix (e.g., #cloudflare-dns.com). In systemd-resolved, appending the Server Name Indication (SNI) hostname enables Server Certificate Authentication, guaranteeing that the upstream server presents a valid TLS certificate matching that exact hostname.
Restarting and Validating systemd-resolved
Save the drop-in file and apply the new configuration by restarting the resolution daemon:
sudo systemctl restart systemd-resolved
Verify that the service is running and active without syntax errors:
sudo systemctl status systemd-resolved
Inspect the active operational DNS configuration across your network interfaces using resolvectl:
resolvectl status
Review the output to confirm that DNSOverTLS=yes is active globally and that the configured upstream IP addresses and SNI hostnames appear under the Global section.
Verifying DNS Over TLS with Wire Traffic and Diagnostic Tools
To confirm that lookups are genuinely encrypted across port 853 and not leaking across cleartext port 53, perform diagnostic queries using resolvectl and monitor network interfaces.
First, test resolution of an external domain:
resolvectl query digitash.com
The command outputs the resolved IP addresses, the resolving interface, response latency, and authentication flags.
Next, use tcpdump to monitor outgoing DNS packets while executing queries in a separate terminal window:
sudo tcpdump -n -i any port 853 or port 53
When running lookup commands, you will observe TLS Application Data packets transmitting back and forth across TCP port 853. Zero packets should appear on cleartext UDP port 53, proving that leak prevention and encryption enforcement are operating as intended.
Troubleshooting Common DoT Resolution Failures
If domain name resolution fails after enabling strict DoT enforcement, review these operational factors:
- Firewall Egress Blocking: Restrictive corporate or public firewalls frequently block outbound TCP port 853. Check outbound rules with
sudo ufw statusand ensure router firewalls permit outbound traffic to port 853. - System Time Drifts: Because TLS certificates require valid timestamp verification, significant system clock skew causes upstream certificate validation errors. Synchronize time via
sudo timedatectl set-ntp true. - NetworkManager Conflict: If NetworkManager dynamically overrides DNS servers via DHCP, add
dns=systemd-resolvedto the[main]section of/etc/NetworkManager/NetworkManager.confand restart NetworkManager.