DNS over TLS (DoT): Port 853, Privacy Profiles, and Deployment

DNS over TLS encrypts DNS queries by wrapping standard DNS messages inside a TLS session on TCP port 853. It is the more conservative of the two encrypted DNS protocols: the message format is unchanged, only the transport is protected, and it runs on a port of its own. That last detail is what makes it the easier of the two for a network operator to live with.

How a DoT session works

The client opens a TCP connection to port 853 on the resolver and performs a TLS handshake, validating the resolver's certificate. Once the session is established, ordinary DNS messages flow inside it, length-prefixed exactly as they are for DNS over TCP.

Sessions are reused. Because a TLS handshake is expensive relative to a DNS lookup, clients keep the connection open and pipeline many queries through it, which makes the steady-state cost close to plain DNS. Idle timeouts are negotiated so resolvers are not holding connections indefinitely.

What is protected is the query and the response in transit: an observer on the path sees that a client contacted a resolver and how much data moved, but not which names were requested. What is not protected is what happens next — the connection to the resolved address still reveals the destination, and TLS Server Name Indication usually discloses the hostname unless encrypted client hello is in use.

Strict versus opportunistic

This distinction is the part most often missed, and it decides whether DoT provides any real assurance.

Opportunistic privacy means the client tries DoT and falls back to plaintext DNS if it fails. It protects against passive eavesdropping and nothing else, because an active attacker simply blocks port 853 and the client downgrades itself.

Strict privacy means the client is configured with the resolver's name and requires a valid certificate matching it. If the connection cannot be made or the certificate does not validate, resolution fails rather than falling back. This protects against active attackers, at the cost of failing closed — which is the correct behavior for a security control and an operational consideration you need to plan for.

Configure strict mode wherever you control both ends. Opportunistic mode is a transitional setting, and treating it as equivalent to strict is a common misconfiguration.

Where DoT sits in the stack

Encryption can be applied at two different hops. Stub to recursive is the common one: the client encrypts to its configured resolver, covering the local network, the Wi-Fi operator, and the internet service provider. Recursive to authoritative encrypts the resolver's upstream queries to authoritative servers, which is far less deployed because authoritative operators must support it.

Most discussion of encrypted DNS means the first hop, and that is where the exposure is for an ordinary user.

Note also that DoT protects the channel, not the data. It does not prove a record is authentic — that is DNSSEC, which signs records and can be validated regardless of transport. A resolver that lies to you over DoT is lying over an encrypted connection. Running both is the complete position, and understanding which DNS record types carry signatures makes the split clearer.

Why operators prefer it to DoH

DoT's dedicated port is an administrative feature. Traffic on 853 is identifiable, so an organization can permit it to approved resolvers and block it elsewhere, and can see at a glance whether encrypted DNS is in use. Policy becomes a firewall rule.

The alternative hides DNS inside ordinary web traffic on port 443 specifically so it cannot be separated, which is excellent for a user on a hostile network and awkward for a security team that needs query visibility. The full comparison and the enterprise controls for both are covered under DNS over HTTPS and DNS over TLS.

The practical enterprise pattern is the same either way: run your own resolver that accepts encrypted queries from internal clients, so the wire is protected while logging and filtering stay in your hands, and keep those resolver logs flowing into your SIEM, where the detection value actually lives.

Deployment notes

Android supports DoT natively as Private DNS, which is why it is the most widely used encrypted DNS protocol on mobile devices even though DoH gets more attention. Common resolver software supports it directly or through a lightweight proxy, and home routers increasingly offer it.

Plan for TCP. DoT is connection-oriented, so firewall state tables and resolver connection limits matter in a way they do not for UDP DNS, and a resolver serving thousands of clients holds thousands of long-lived sessions.

Exam angles

Know that DoT uses TCP port 853 and DoH uses TCP 443, and be able to explain why the separate port makes DoT easier to govern. Distinguish strict from opportunistic privacy and recognize that opportunistic mode is defeated by an active attacker. Remember that encrypted DNS provides confidentiality and integrity in transit while DNSSEC provides authenticity of records, and that the two are complementary rather than alternatives.