How to Configure systemd-resolved DNS over TLS on Ubuntu

Modern network tracking and man-in-the-middle tampering frequently target plaintext domain name resolution queries transmitted across public UDP and TCP port 53. DNS over TLS (DoT) encrypts all outgoing domain lookups between your local resolver and upstream recursive resolvers using Transport Layer Security across dedicated TCP port 853. Rather than deploying third-party forwarding proxies or redundant daemons, Ubuntu systems integrate native DoT capabilities directly into the core systemd-resolved network caching and resolution stack.

Understanding systemd-resolved Architecture and Encryption Modes

In Ubuntu, local application name resolution requests are routed through the local stub resolver listening on loopback address 127.0.0.53:53. The underlying daemon, systemd-resolved.service, accepts standard queries from system libraries and handles outbound resolution to configured upstream nameservers. When configuring DNS over TLS, systemd provides two operational directives within resolved.conf:

• opportunistic: Attempts establishing TLS handshake across port 853 with configured nameservers. If the upstream provider rejects the TLS handshake or suffers network timeouts, the daemon automatically falls back to unencrypted plaintext queries over UDP port 53.
• yes (strict): Mandates TLS encryption across port 853 for all outbound recursive queries. If the upstream nameserver fails to establish an authenticated TLS session, the query is blocked immediately, preventing silent unencrypted data leakage.

Configuring Upstream Resolvers and Enabling DNS over TLS

Systemd configuration files are organized hierarchically. To ensure modifications persist cleanly across package updates without altering base defaults in /etc/systemd/resolved.conf, administrators should deploy custom configuration drop-in snippets within /etc/systemd/resolved.conf.d/.

Create the drop-in configuration directory and establish a custom configuration file:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo nano /etc/systemd/resolved.conf.d/dns_over_tls.conf

Append the following configuration directives to designate authenticated upstream DoT providers (such as Cloudflare or Quad9) alongside server name indication (SNI) hostnames for cryptographic certificate verification:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com
FallbackDNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNSOverTLS=yes
DNSSEC=allow-downgrade
MulticastDNS=no
LLMNR=no
Cache=yes

The syntax IP_ADDRESS#HOSTNAME explicitly associates the designated IP address with the cryptographic common name expected in the upstream TLS certificate, preventing man-in-the-middle server spoofing.

Applying Service Updates and Validating DNS Symlinks

Ubuntu applications rely on /etc/resolv.conf to discover the active stub resolver. Ensure the resolv.conf file is correctly symlinked to the systemd stub file before restarting the service:

# Verify symlink points to stub-resolv.conf
ls -la /etc/resolv.conf

# Recreate symlink if pointing elsewhere
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# Restart systemd-resolved to apply TLS directives
sudo systemctl restart systemd-resolved.service

Verifying Active TLS Encryption and Upstream Handshakes

To confirm that domain resolution queries are actively transmitted over encrypted TLS tunnels, run the built-in systemd query diagnostic tool:

resolvectl status

Review the output section corresponding to your primary network link and global settings. The report should display:

Global
           Protocols: -DefaultRoute +DNS -LLMNR -mDNS +DNSOverTLS DNSSEC=allow-downgrade/supported
    Current DNS Server: 1.1.1.1#cloudflare-dns.com
           DNS Servers: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
   Fallback DNS Servers: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
           DNS Over TLS: yes

Auditing Network Traffic with tcpdump

The definitive verification of DNS over TLS operation is packet-level auditing. Open an active terminal and monitor traffic directed at port 53 versus port 853 during a test query:

# Monitor port 853 in one terminal
sudo tcpdump -i any port 853 -n -c 5

# Send a domain lookup in another terminal
resolvectl query canonical.com

The tcpdump monitor will record immediate bidirectional TCP packet exchanges across port 853 containing encrypted TLS payloads, while monitoring port 53 yields zero outbound packets. Encrypting system-level DNS prevents local ISP interception and guarantees tamper-proof domain resolution across all Ubuntu workstations and servers.