What Is DNS over TLS?

How DNS over TLS Works

DNS over TLS was standardized in RFC 7858 in 2016. It operates by establishing a standard TLS handshake on TCP port 853 between your device (or resolver) and the DoT-capable DNS server. Once the encrypted channel is open, DNS queries and responses are sent in their normal wire format — the same binary format used by plaintext DNS — but wrapped inside the TLS session. The content is encrypted and the server's identity is verified by its TLS certificate, preventing both eavesdropping and impersonation.

A key efficiency feature is connection persistence. Rather than opening a new TLS connection for every query — which would require a full handshake each time — DoT clients reuse the same TCP connection for multiple sequential queries. This makes the per-query overhead after the first connection very low, comparable to the overhead of persistent connections in HTTP/1.1.

DoT vs DoH: The Key Differences

Both DNS over TLS and DNS over HTTPS encrypt DNS queries, but they make different architectural choices with real-world consequences. DoT uses a dedicated TCP port 853, which is assigned exclusively for encrypted DNS. DoH uses the standard HTTPS port 443, which it shares with all other web traffic.

This port choice creates an important practical difference in network visibility. Because DoT uses its own port, a network administrator can immediately identify DoT traffic and choose to allow, monitor, or block it without touching other traffic. A simple firewall rule dropping port 853 disables DoT entirely. DoH, by contrast, cannot be blocked at the port level without also blocking all HTTPS — making it effectively unblockable on networks where web access is required.

From an enterprise IT perspective, DoT's identifiability is an advantage — it allows controlled deployment and monitoring. From a privacy-first perspective, DoH's blending with regular traffic makes it more resilient against network-level censorship. The right choice depends on your context.

Android's Private DNS: DoT Built Into the OS

Android 9 (Pie) was the first major operating system to build DoT support directly into the OS, under the name Private DNS. When you configure Private DNS with a resolver hostname, Android establishes a persistent TLS connection to that hostname on port 853 and routes all DNS queries from the device — across all apps, all networks, both Wi-Fi and mobile data — through that encrypted channel. This is system-level DoT, not per-app or per-browser, which makes it more comprehensive than browser-based DoH.

Android's Private DNS operates in two modes. Opportunistic mode (the default "Automatic" setting) attempts DoT with the network's configured DNS server if it supports it, but falls back to plaintext if the server does not. Strict mode is activated when you specify a hostname — Android will only use that encrypted resolver and will fail DNS resolution entirely if it cannot establish a TLS connection, rather than falling back to plaintext.

How to Enable DoT on Android

On Android 9 or later, go to Settings → Network & Internet → Private DNS. On Samsung One UI devices, the path is Settings → Connections → More connection settings → Private DNS. Select Private DNS provider hostname and enter one of the following: 1dot1dot1dot1.cloudflare-dns.com for Cloudflare, dns.google for Google Public DNS, or dns.quad9.net for Quad9. Tap Save. Android will immediately switch to encrypted DNS on port 853 for all queries. The connection applies to both Wi-Fi and cellular — you do not need to configure it per network.

Router and Linux Support for DoT

Several router platforms support DoT as a forwarding option, allowing all devices on your network to benefit from encrypted DNS without configuring individual devices. Ubiquiti UniFi routers support DoT in their DNS Shield feature. pfSense and OPNsense support DoT through their DNS Resolver (Unbound) configuration. Some consumer routers running DD-WRT or OpenWRT firmware can be configured to use DoT via the Unbound or Stubby packages.

On Linux systems using systemd-resolved, DoT can be enabled by editing /etc/systemd/resolved.conf and setting DNSOverTLS=yes along with a supporting resolver in the DNS= field. Restart the service with sudo systemctl restart systemd-resolved. The Stubby daemon is an alternative for systems without systemd-resolved — it acts as a local DoT proxy and forwards queries from your local stub resolver to a DoT-capable upstream server.

DoT Resolver Hostnames

Unlike plaintext DNS which uses IP addresses, DoT configuration requires a hostname so that the TLS certificate can be verified. Cloudflare's DoT hostname is 1dot1dot1dot1.cloudflare-dns.com (resolving to 1.1.1.1 and 1.0.0.1). Google's hostname is dns.google (resolving to 8.8.8.8 and 8.8.4.4). Quad9's hostname is dns.quad9.net (resolving to 9.9.9.9). NextDNS provides unique per-account hostnames that apply your custom configuration over DoT. These hostnames are used by Android's Private DNS field, Linux's systemd-resolved, and DoT-capable router firmware.

Performance: Persistent Connections Reduce Overhead

A common concern about DoT is latency — the TLS handshake adds round trips before the first query can be sent. In practice, this initial cost is paid once per connection, not per query. After the handshake, subsequent queries over the same connection add only the network round-trip time, the same as plaintext DNS. On Android, the persistent DoT connection is maintained in the background even when not actively querying, so the handshake cost rarely affects real query latency for the user. Benchmarks consistently show DoT query times within a few milliseconds of plaintext DNS once the connection is warm.

DoT vs DoH vs Plaintext DNS

Frequently Asked Questions

What port does DNS over TLS use?

DNS over TLS uses TCP port 853, which was specifically assigned for this purpose by IANA when DoT was standardized in RFC 7858 in 2016. Using a dedicated port means DoT traffic is clearly identifiable on a network — a network administrator can see that port 853 connections are DNS queries, even though the content is encrypted. This distinguishes DoT from DNS over HTTPS, which blends into regular HTTPS traffic on port 443 and cannot be selectively blocked without disrupting all web traffic.

How do I enable DNS over TLS on Android?

Android 9 and later support DoT natively through the Private DNS feature. Go to Settings, then Network and Internet (or Connections on Samsung devices), then Private DNS. Select 'Private DNS provider hostname' and enter the hostname of a DoT-capable resolver: 1dot1dot1dot1.cloudflare-dns.com for Cloudflare, dns.google for Google, or dns.quad9.net for Quad9. Tap Save. Android will establish a persistent TLS connection to that resolver hostname on port 853 and route all DNS queries through it, across both Wi-Fi and mobile data connections.

Can network admins block DNS over TLS?

Yes. Because DoT uses a dedicated port 853, network administrators can block it with a simple firewall rule that drops all traffic on port 853. This is one of the key practical differences between DoT and DoH — DoH on port 443 cannot be blocked without also blocking all HTTPS traffic, while DoT can be selectively blocked. In enterprise environments, blocking port 853 forces devices to fall back to the network's configured DNS resolver, which is often the desired behavior for IT policy enforcement.

Is DoT faster than DoH?

DoT and DoH have comparable latency in practice. DoT opens a persistent TCP connection with TLS on port 853 and then sends DNS messages directly over that channel. DoH wraps queries in HTTP/2 frames over a similar TLS connection on port 443. The HTTP/2 framing in DoH adds a small amount of overhead per query, but HTTP/2 multiplexing can reduce head-of-line blocking for concurrent queries. The real-world difference is typically a few milliseconds and not perceptible to users. Both are significantly more private than plaintext DNS on port 53.

What is the difference between strict and opportunistic DoT mode?

Strict mode requires a successful TLS connection to the specified DoT resolver hostname before any DNS query is sent. If the TLS handshake fails — because the server is unreachable, presents an invalid certificate, or port 853 is blocked — DNS resolution fails entirely rather than falling back to plaintext. Opportunistic mode attempts DoT but falls back to plaintext DNS if the encrypted connection cannot be established. Strict mode provides a strong security guarantee; opportunistic mode prioritizes availability. Android's Private DNS feature operates in strict mode when a hostname is specified.

Does DNS over TLS protect against DNS hijacking?

DNS over TLS protects against man-in-the-middle DNS hijacking — attacks where an attacker on the network path intercepts and modifies DNS responses in transit. The TLS encryption and server certificate verification ensure that only the authenticated resolver can read and respond to your queries. However, DoT does not protect against local DNS hijacking (malware that changes your device's resolver settings) or router hijacking (an attacker who has already compromised your router). For comprehensive DNS security, combine DoT with DNSSEC validation at the resolver and strong router credentials.