DNS over TLS: How DoT Encrypts Resolver Traffic

DNS over TLS (DoT) sends ordinary DNS messages over an encrypted TLS connection. The client opens a TCP connection to the resolver, completes a TLS handshake, authenticates the resolver when required, and then sends DNS queries and receives responses through that encrypted session.

A dedicated TLS connection on port 853

RFC 7858 defines DoT as DNS over a TCP connection protected by TLS, on its own well-known port:

DNS over UDP/TCP: 53
DNS over TLS:     853

A client connecting to a default DoT service opens TCP port 853 and starts with a TLS handshake. Cleartext DNS isn’t sent first and then upgraded. The connection is meant to be encrypted from the start, and RFC 7858 prohibits mixing cleartext DNS and DoT on a port designated for DoT.

The dedicated port makes DoT easy to identify. A network device can treat a connection to port 853 as likely DoT even though it can’t read the encrypted payload without access to the TLS session.

The DNS message keeps its TCP framing

Classic DNS over TCP prefixes each message with a two-octet length field, and DoT keeps that framing inside the TLS connection:

TLS application data
+--------------------+
| 2-byte DNS length  |
+--------------------+
| DNS message        |
+--------------------+

The DNS message after the length field is the normal wire format. DoT doesn’t define a new format for A, AAAA, MX, TXT, or DNSSEC-related records like DNSKEY, DS, and RRSIG. It wraps the existing TCP form of a DNS message in TLS, and the resolver reads the same header and sections it would over any other transport.

Encryption and authentication are separate jobs

Once the handshake succeeds, TLS encrypts the connection and detects tampering inside it. Whether the client reached the intended resolver, rather than some server willing to negotiate TLS, is a separate question, and resolver authentication answers it. Without it, an active attacker can terminate the client’s TLS and open its own connection onward, reading or changing every query. That split is why encrypted DNS privacy is about more than whether packets are encrypted, and it produced the two usage profiles in RFC 8310.

Strict Privacy requires an encrypted and authenticated connection to the configured resolver. If that authenticated service is unavailable, a strict client fails rather than quietly continuing in cleartext. The client needs authentication information for the resolver, either an authentication domain name (verified with PKIX certificates or DANE) or an SPKI pin set:

Configured resolver:
  address: 192.0.2.53
  authentication name: resolver.example

Opportunistic Privacy tries encrypted DNS when it can, but makes no guarantee. RFC 8310 allows an opportunistic client to end up on an authenticated encrypted connection, an unauthenticated encrypted one, or cleartext. It improves confidentiality against a passive observer when encryption is available, but an active attacker who blocks port 853 can force cleartext fallback, so it offers no guaranteed protection against an active attacker.

One connection, many queries

A new TCP connection adds a round trip, and TLS adds more, typically one round trip with TLS 1.3 and historically two for a full TLS 1.2 handshake, less with session resumption. Opening a fresh connection per question would pile that on for every lookup, so RFC 7858 recommends reusing the connection and pipelining queries, sending the next before the previous answer returns:

TCP + TLS connection
    +-- query 1  -->
    +-- query 2  -->
    +-- query 3  -->
    <-- response 1
    <-- response 2
    <-- response 3

DNS workloads are naturally concurrent, since applications fire many lookups close together, and serializing each behind the last would add latency for no reason. Servers can still close idle connections, so clients have to handle connection loss and reconnect.

A recognizable service with an unreadable payload

Using a dedicated port gives DoT a different visibility tradeoff from DNS over HTTPS. A network can classify a TCP port 853 connection as likely DoT and apply port-based policy, though 853 is only the default (DoT can run on another mutually configured port) and a port number alone doesn’t prove the application protocol. DoQ presents the same dedicated-port footprint on UDP 853. What a passive observer without the session keys can’t do is read the QNAME or answer out of the TLS payload, although it still sees the endpoints, timing, and message sizes and can draw inferences from them. A network can identify DoT traffic without learning which name it resolved.

Past the resolver, it’s ordinary DNS

DoT protects a connection, not the whole hierarchy. The common case is stub-to-recursive:

Application -> stub or local resolver --DoT--> recursive resolver -> authoritative DNS

The TLS session covers the leg between the DoT client and the recursive resolver. Beyond that, the resolver performs ordinary recursion, and using DoT on the first leg doesn’t require every recursive-to-authoritative exchange to use TLS. That’s the same boundary described in Encrypted DNS: Privacy vs. Anonymity, where encryption protects a defined connection rather than turning the whole DNS hierarchy into one end-to-end encrypted session.

Once the DoT server has the message, normal resolver behavior resumes. It checks its cache and answers or resolves the name through the hierarchy. TTL behavior doesn’t change because the question arrived over TLS, and neither do records, delegations, DNSSEC validation, or NXDOMAIN handling. The encrypted connection protects the transport without redefining the DNS data carried through it.

Authentication needs a starting point

A client can only authenticate an identity it already knows to expect. A traditional DNS client may start with only an IP address learned from static configuration, DHCP, or a VPN, while TLS authentication usually works from a service name and its credentials. RFC 8310 treats this as a startup-configuration problem. The client needs a trusted way to associate the resolver with an authentication domain name or another accepted mechanism.

The problem is general, not unique to DoT, and newer standards add mechanisms for discovering encrypted resolvers. Authentication can protect a connection from an active attacker only after the client knows enough about the intended peer to establish the right one in the first place.

Summary

DNS over TLS sends ordinary DNS messages through an encrypted TLS connection, normally on TCP port 853. The Strict and Opportunistic profiles decide what a client does when encryption or authentication fails.

DoT only changes the connection used to reach the resolver. Everything past that point behaves as ordinary DNS, and DoH and DoQ do the same job over HTTPS and QUIC instead.