How DNS over TLS (DoT) Works: Encrypting DNS on Port 853

DNS over TLS (DoT) is a protocol standardized in RFC 7858 that encrypts DNS queries by wrapping them in a TLS connection on a dedicated port (853). Traditional DNS sends queries and responses as plaintext UDP datagrams on port 53, allowing anyone on the network path -- your ISP, a compromised router, a state surveillance system -- to observe, log, and even modify every domain name you look up. DoT eliminates this exposure by encrypting the transport layer between stub resolvers and recursive resolvers, providing confidentiality and integrity for DNS traffic without changing the DNS wire format itself.

The Problem: DNS as a Plaintext Protocol

DNS was designed in 1983 (RFC 882 and RFC 883, later consolidated into RFC 1034 and RFC 1035) with no consideration for privacy. Every DNS query contains the domain name being resolved, the query type, and the source IP of the requester. Every response contains the answer. Both travel in plaintext.

This creates several concrete problems:

• Passive surveillance -- Any entity on the network path can silently log every domain a user visits. ISPs routinely collect DNS data for analytics, advertising, or compliance with government data retention laws.
• Active manipulation -- Without encryption, an on-path attacker can modify DNS responses to redirect users to malicious servers. This is distinct from the forgery attacks that DNSSEC addresses -- even with DNSSEC, the query itself (which domain you are looking up) remains visible without transport encryption.
• Censorship -- Governments and network operators inspect plaintext DNS to enforce blocking lists. By reading the domain in the query, they can drop or forge responses for banned domains.
• Wi-Fi eavesdropping -- On open wireless networks, any other user can capture DNS queries and build a complete browsing profile.

DNSSEC provides authentication and integrity -- it proves that a DNS answer has not been tampered with -- but it does not encrypt queries. An observer still sees which domains you query. DoT and DNS over HTTPS (DoH) address the confidentiality gap.

How DNS over TLS Works

DoT is conceptually straightforward: take a standard DNS message (the same binary format defined in RFC 1035) and send it over a TLS-encrypted TCP connection to port 853 on the recursive resolver. The DNS message format does not change at all -- the encryption happens at the transport layer below it.

The process works as follows:

1. TCP connection -- The client (stub resolver) opens a TCP connection to the recursive resolver on port 853.
2. TLS handshake -- The client and server perform a standard TLS handshake. The server presents its certificate. Depending on the authentication mode (strict or opportunistic), the client may or may not validate this certificate.
3. DNS query -- Once the TLS session is established, the client sends a DNS query prefixed with a two-byte length field (as specified in RFC 1035 Section 4.2.2 for TCP). The query itself is the same binary format as traditional DNS.
4. DNS response -- The server responds with a standard DNS response, also length-prefixed, over the same TLS connection.
5. Connection reuse -- The TLS connection remains open for subsequent queries, amortizing the handshake cost across multiple lookups.

The TLS Handshake for DNS

The TLS handshake for DoT is identical to any other TLS handshake. With TLS 1.3 (which all modern DoT implementations support), this is a single round-trip:

1. ClientHello -- The client sends supported cipher suites, a key share (for Diffie-Hellman key exchange), and the TLS version. In DoT, the SNI (Server Name Indication) field typically contains the resolver's hostname, such as dns.google or one.one.one.one.
2. ServerHello -- The server selects a cipher suite, sends its key share, its certificate chain, and completes the handshake in a single flight.
3. Finished -- The client verifies the server's certificate, completes its side of the key exchange, and sends the Finished message. From this point, all data is encrypted with the negotiated session keys.

With TLS 1.3, the handshake completes in one round-trip (1-RTT), and subsequent connections to the same resolver can use 0-RTT resumption to send data immediately. However, 0-RTT data is vulnerable to replay attacks, so DoT implementations must be careful about what they allow in early data.

Connection Reuse and Performance

The biggest performance concern with DoT is latency. A plaintext DNS query over UDP takes a single round-trip: send the query, receive the response. DoT requires establishing a TCP connection (1 RTT) and performing a TLS handshake (1 RTT with TLS 1.3, 2 RTT with TLS 1.2) before the first query can be sent. That is 2-3 round-trips before you get your first DNS answer, compared to one for traditional DNS.

RFC 7858 addresses this by strongly recommending connection reuse. Rather than opening a new TLS session for every query, the client keeps the connection open and sends multiple queries over the same session. This amortizes the handshake cost:

• First query: 2-3 RTTs (TCP + TLS + query/response)
• Subsequent queries: 1 RTT (query/response only, TLS session already established)
• With TLS session resumption: 1-2 RTTs for reconnection after idle timeout
• With TLS 1.3 0-RTT: Potentially 1 RTT even for the first query on a resumed session

In practice, a persistent DoT connection to a resolver like 1.1.1.1 or 8.8.8.8 introduces negligible overhead for typical browsing, since most DNS queries after the initial burst use the existing connection. The stub resolver handles connection management transparently -- applications issue DNS queries the same way they always have.

RFC 7858 also permits pipelining: sending multiple DNS queries without waiting for responses. The two-byte length prefix on each message allows the receiver to frame messages on the TCP stream. This enables a burst of queries at the start of a page load (where a browser might resolve a dozen domains simultaneously) to complete in a single round-trip over an already-established connection.

Strict vs. Opportunistic Mode

DoT can operate in two authentication modes, and the distinction is critical for understanding its real-world security properties:

Strict Mode (RFC 8310)

In strict mode, the client validates the resolver's TLS certificate against a known identity. The client is pre-configured with the resolver's hostname (e.g., dns.google) or its SPKI (Subject Public Key Info) pin. If the certificate does not match, the connection is refused and the query fails -- the client does not fall back to plaintext DNS.

Strict mode provides genuine protection against man-in-the-middle attacks. An attacker who intercepts the connection to port 853 cannot present a valid certificate for dns.google (unless they have compromised the CA system or stolen Google's private key). The client will reject the connection entirely.

The downside: strict mode requires out-of-band configuration. The user or device must be pre-configured with the identity of a trusted DoT resolver. There is no way to "discover" that a resolver supports DoT and automatically verify it without some prior knowledge.

Opportunistic Mode

In opportunistic mode, the client attempts a TLS connection to port 853 but does not validate the server's certificate. If the connection succeeds, queries are encrypted. If port 853 is unreachable or the TLS handshake fails, the client falls back to plaintext DNS on port 53.

Opportunistic mode protects against passive surveillance (eavesdroppers who are recording traffic but not actively modifying it) but not against active attackers. An on-path attacker can either block port 853 (forcing fallback to plaintext) or present their own certificate (which the client will accept without validation). It is better than nothing, but it is not a security guarantee.

Most operating system DoT implementations default to opportunistic mode when the user simply enables "Private DNS" without specifying a resolver hostname. Android's Private DNS feature, for instance, operates in strict mode when a hostname is entered but opportunistic mode when set to "Automatic."

DNS Query Padding (RFC 7830)

Even with TLS encryption, DNS traffic leaks information through message sizes. DNS queries and responses have characteristic lengths -- a query for a.com is much shorter than one for very-long-subdomain.example.co.uk. An observer who cannot read the encrypted content can still perform traffic analysis, correlating message sizes and timing to infer which domains are being queried.

RFC 7830 defines a DNS padding option (EDNS0 option code 12) that allows clients and servers to pad DNS messages to a uniform size. RFC 8467 provides specific guidance on padding strategies for DoT:

• Block-length padding -- Pad every query to the next multiple of a fixed block size (e.g., 128 bytes). This reduces the number of distinct observable message sizes from thousands to a handful, making traffic analysis much harder.
• Random-length padding -- Add a random number of padding bytes. This provides less predictable message sizes but can be less effective than block padding against statistical analysis.
• Maximum-length padding -- Pad every message to the maximum allowed size (512 bytes for queries without EDNS0, or the EDNS0 buffer size). This eliminates size-based correlation entirely but wastes significant bandwidth.

The recommended approach from RFC 8467 is block-length padding with a block size of 128 bytes for queries and 468 bytes for responses. This provides a good balance between privacy and overhead.

DoT vs. DoH vs. DoQ: Encrypted DNS Compared

Three major protocols compete to encrypt DNS traffic. Each makes different architectural tradeoffs:

DNS over TLS (DoT)

DoT uses a dedicated port (853), which makes it easy for network administrators to identify and manage. Enterprise networks can allow DoT to approved resolvers while blocking it to others. However, this same identifiability means that censors can trivially block all DoT traffic by blocking port 853. In countries like China, Iran, and Russia, port 853 is widely blocked.

DoT operates at the system level. When Android, iOS, Linux (via systemd-resolved), or Windows is configured to use DoT, all applications on the device benefit from encrypted DNS without any per-application configuration.

DNS over HTTPS (DoH)

DNS over HTTPS encapsulates DNS queries in HTTP/2 requests over port 443 -- the same port used for all HTTPS web traffic. This makes DoH nearly impossible to distinguish from regular web browsing, which is both its greatest strength (resistance to blocking) and its greatest controversy (network administrators lose visibility into DNS traffic on their networks).

DoH is primarily deployed in browsers (Firefox, Chrome, Edge, Safari) and operates at the application level. This means a browser can use a different DNS resolver than the system, which has led to significant debate about DNS centralization and the role of browser vendors in DNS policy.

DNS over QUIC (DoQ)

DoQ (RFC 9250) runs DNS over QUIC, which provides TLS 1.3 encryption natively with lower latency than TCP-based protocols. QUIC's independent stream multiplexing eliminates head-of-line blocking -- if one DNS response is delayed, it does not block other responses on the same connection. DoQ uses UDP port 853, matching DoT's port number but over UDP rather than TCP. It is the newest of the three protocols and is still in early deployment.

Privacy Implications and Resolver Trust

DoT encrypts the path between your device and the recursive resolver. This solves the surveillance problem at the network layer, but it does not eliminate all DNS privacy concerns:

• Resolver trust -- The recursive resolver still sees every query in plaintext (it has to, in order to resolve the queries). DoT shifts visibility from your ISP (who can sniff port 53) to your chosen resolver operator. If you use Cloudflare (1.1.1.1), Cloudflare sees your queries. If you use Google (8.8.8.8), Google sees them. You are trading one trust relationship for another.
• SNI leakage -- Even with encrypted DNS, when your browser connects to a website using TLS, the TLS ClientHello message includes the server's hostname in the SNI field -- in plaintext. So an observer may not see your DNS query for example.com, but they see you connecting to example.com in the TLS handshake moments later. Encrypted Client Hello (ECH) addresses this, but deployment is still limited.
• IP address correlation -- Even without SNI, the destination IP addresses of your connections are visible. Many websites have unique IP addresses, so an observer can still infer which sites you visit from IP addresses alone.
• QNAME minimization (RFC 7816) -- A complementary privacy technique where the recursive resolver sends only the necessary part of the domain name to each authoritative server in the chain, rather than the full query name. Combined with DoT, this reduces exposure at every hop.

The most privacy-conscious configuration combines DoT in strict mode with a trusted resolver that supports QNAME minimization, uses a resolver that commits to minimal or no logging, and uses Encrypted Client Hello for web connections. Even then, traffic analysis based on timing, volume, and destination IPs remains possible.

Deployment in Practice

DoT has seen broad deployment across operating systems and resolver services:

Client Support

• Android 9+ -- Native "Private DNS" feature. Set to "Automatic" for opportunistic mode or enter a hostname (e.g., dns.google) for strict mode. This encrypts DNS for every app on the device.
• iOS/macOS -- Supported via configuration profiles (MDM) or apps. Apple introduced native DNS settings API in iOS 14 and macOS 11, allowing apps to register system-wide DoT or DoH configurations.
• Linux -- systemd-resolved supports DoT since version 239. Configuration is via /etc/systemd/resolved.conf with the DNSOverTLS= directive set to yes (strict) or opportunistic.
• Windows -- Windows 11 added DoT support alongside DoH. Configuration is through network adapter settings or Group Policy.
• Stubby -- A dedicated DoT stub resolver from the getdnsapi project, designed specifically for encrypting DNS on the local machine and forwarding queries to a DoT-capable recursive resolver.

Resolver Support

• Cloudflare (1.1.1.1) -- one.one.one.one or cloudflare-dns.com on port 853
• Google Public DNS (8.8.8.8) -- dns.google on port 853
• Quad9 (9.9.9.9) -- dns.quad9.net on port 853, with malware blocking
• Unbound -- Open-source recursive resolver with full DoT support, commonly used for self-hosted encrypted DNS
• Knot Resolver -- Another open-source resolver with DoT and DoH support

DoT and Network Policy

DoT's use of a dedicated port has important implications for network operators:

• Enterprise networks -- Organizations can firewall port 853 to prevent employees from bypassing corporate DNS policies (content filtering, security monitoring, compliance logging). They can also run their own internal DoT resolvers, providing encrypted DNS while maintaining policy enforcement.
• Parental controls -- Home routers that enforce parental controls through DNS filtering can block port 853 to prevent devices from circumventing filters. This is more difficult with DoH, which blends into regular HTTPS traffic.
• ISP policies -- Some ISPs block port 853 to maintain visibility into DNS traffic for threat detection or lawful intercept compliance. Others have deployed DoT on their own resolvers, offering encrypted DNS while retaining their position as the default resolver.

This creates a fundamental tension in the encrypted DNS debate. DoT gives network operators a clear signal to manage ("this is encrypted DNS traffic"), while DoH deliberately obscures that signal. Which approach is "better" depends entirely on whether you view network-level DNS visibility as a feature (for security monitoring and policy enforcement) or a bug (for user privacy and censorship resistance).

Security Considerations

Several security aspects are specific to DoT deployment:

• Downgrade attacks -- In opportunistic mode, an active attacker can block port 853 and force the client to fall back to plaintext DNS. Only strict mode prevents this, at the cost of failing closed (no DNS resolution) if the DoT resolver is unreachable.
• Certificate validation -- DoT relies on the same PKI infrastructure as HTTPS. A compromised Certificate Authority could issue a fraudulent certificate for a DoT resolver's hostname, enabling interception. Certificate Transparency logs help detect such incidents.
• Denial of service -- Since DoT requires TCP, it is more susceptible to state-exhaustion attacks than plaintext UDP DNS. Resolvers must handle connection management carefully to avoid resource exhaustion from many half-open connections.
• Implementation bugs -- TLS implementations are complex and have historically been a source of vulnerabilities (Heartbleed, POODLE, BEAST). DoT inherits whatever vulnerabilities exist in the underlying TLS library.

DoT and the Broader Internet Architecture

DNS over TLS is part of a broader movement to encrypt all internet infrastructure protocols. DNS was one of the last major plaintext protocols, alongside protocols like the initial BGP session negotiation. The push to encrypt DNS reflects a recognition that metadata -- who you communicate with, when, and how often -- can be as sensitive as the content of the communication itself.

The routes that carry DoT traffic are themselves visible in the global BGP routing table. You can observe the network paths to major DoT resolvers, see which autonomous systems transit the traffic, and understand the physical topology that your encrypted queries traverse. The encryption protects the content; BGP determines the path.

Explore DNS Infrastructure with the Looking Glass

Use the god.ad BGP Looking Glass to trace the routes to major DoT resolver addresses and understand how encrypted DNS traffic traverses the internet. Look up Cloudflare's 1.1.1.1, Google's 8.8.8.8, or Quad9's 9.9.9.9 to see the BGP routes, origin ASNs, and network paths that carry your encrypted DNS queries. Examine the AS13335 (Cloudflare) or AS15169 (Google) to see how these resolver networks peer with the rest of the internet.