DNS over TLS Explained: Port 853, Android, Linux and DoT vs DoH

How DNS over TLS works

The client opens a TCP connection to the resolver, completes a TLS handshake, then sends ordinary DNS messages through the encrypted channel. RFC 7858 asks both sides to keep the connection open after each answer and lets the client pipeline queries, matching each response by its message ID. That reuse keeps the protocol from feeling slow.

The RFC describes two privacy profiles. With the opportunistic profile the client tries encryption without insisting on authenticating the server, so an attacker on the path can still strip the protection. With the out-of-band key-pinned profile the client connects only to a server whose key matches a preconfigured pin. systemd-resolved checks a certificate hostname instead.

Why DNS over TLS uses port 853

RFC 7858 is explicit: a server that supports the protocol must listen for TCP connections on port 853 by default, and nobody may use port 853 for cleartext DNS. A different port needs mutual agreement, and port 53 is ruled out, so a plain query and an encrypted one never share a number.

Operators follow the default. Cloudflare runs DoT on port 853 at one.one.one.one, Google Public DNS at dns.google, and Quad9 at dns.quad9.net, with an alternate on port 8853 for restrictive networks. The DNS port guide puts port 853 next to the other DNS port numbers, including DNS over QUIC, which reuses the same number over UDP.

Turning it on: Android, Linux and command-line tests

On Android 9 and later, the system client is the Private DNS setting. Choose the provider hostname option and enter one of the names above, without a scheme or port. Android sends lookups from apps using the system resolver over TLS, and marks the network as offline if the server is unreachable. The Private DNS guide covers every mode.

On Linux with systemd-resolved, two lines in resolved.conf are enough. DNS=9.9.9.9#dns.quad9.net names the server and, after the #, the hostname used to validate its certificate and for SNI. DNSOverTLS=yes then requires encryption for every connection. The value opportunistic tries TLS and falls back when the server lacks it, and the default is no.

To test a server before relying on it, Cloudflare documents a kdig command that checks the certificate as well: kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.one example.com. BIND’s dig accepts +tls, which uses port 853 by default. An answer means the path works; a timeout on a network that answers plain DNS usually means port 853 is filtered.

What it protects and what it does not

Inside the tunnel, queries and answers are encrypted and, when the client checks the certificate, authenticated. Other users on the same Wi-Fi, the hotspot operator and the access provider can no longer read or rewrite them. The resolver itself still sees every query, so choosing the operator remains the real privacy decision, as it is with every encrypted protocol.

RFC 7858 also notes that encryption alone does not hide message sizes. Padding is optional, and the RFC warns that simple padding schemes may not defeat traffic analysis. A visible TCP connection to a known DoT server on port 853 also tells any observer that encrypted DNS is in use, even though the names stay hidden.

DoT vs DoH on real networks

The cryptography is comparable; the difference is visibility. DNS over TLS has its own port, so a firewall can recognise it and block it with one rule. DoH travels on port 443 inside ordinary HTTPS, where blocking it means blocking the web. The DNSCrypt FAQ makes the point directly: a dedicated port is easy to block where encryption matters most.

That makes the DoT vs DoH choice mostly practical. DoT suits networks you control and devices with a built-in client, such as Android phones and Linux machines running systemd-resolved. DoH or DNSCrypt suits hotel, campus and corporate networks that filter unusual ports. The DoH vs DoT comparison and the DNS over HTTPS page cover the alternative in depth.

If DoT keeps failing

Confirm the hostname first, then test the same server with kdig from another network. If it works elsewhere, the local network blocks port 853. Try Quad9’s alternate port, switch Android to Automatic on that network, or move to a client that speaks DNSCrypt or DoH on port 443. dnscrypt-proxy skips DoT but handles both of those.