Section 4.4.1 📖 ~10 min read

DNS-over-TLS (DoT)

The first standardized encrypted DNS transport — how it works, where it's deployed, and how it compares to DNS-over-HTTPS.

Before DoH grabbed the headlines, there was DNS-over-TLS. Published as RFC 7858 in May 2016 — two years before DoH’s RFC 8484 — DoT was the first standardized protocol for encrypting DNS queries between stub resolvers and recursive resolvers.

While DoH won the browser wars, DoT has carved out a significant role in operating system-level DNS encryption, particularly on Android and Linux. Understanding DoT — and how it differs from DoH — is essential for grasping the full landscape of encrypted DNS.

How DoT Works

DNS-over-TLS is architecturally simpler than DoH. Instead of tunneling DNS inside HTTP, DoT wraps standard DNS messages directly in a TLS connection on a dedicated port: 853.

The Connection Flow

  1. The client opens a TCP connection to the DoT server on port 853
  2. A standard TLS handshake occurs (TLS 1.2 or 1.3)
  3. After the handshake, the client sends DNS queries as length-prefixed binary messages (the same TCP wire format defined in RFC 1035 §4.2.2)
  4. The server responds with standard DNS messages, also length-prefixed
  5. Multiple queries can be pipelined on the same connection
Client                           DoT Server (port 853)
  │                                    │
  │──── TCP SYN ──────────────────────>│
  │<─── TCP SYN-ACK ──────────────────│
  │──── TCP ACK ──────────────────────>│
  │                                    │
  │──── TLS ClientHello ──────────────>│
  │<─── TLS ServerHello + Cert ────────│
  │──── TLS Finished ────────────────->│
  │<─── TLS Finished ─────────────────│
  │                                    │
  │──── DNS Query (encrypted) ────────>│
  │<─── DNS Response (encrypted) ──────│
  │                                    │
  │──── DNS Query 2 (encrypted) ──────>│
  │<─── DNS Response 2 (encrypted) ────│
  └────────────────────────────────────┘

That’s it. No HTTP framing, no URI templates, no content types. Just TLS wrapping the same DNS messages that would otherwise travel over plaintext UDP or TCP.

Connection Management

RFC 7858 recommends that clients maintain persistent connections to avoid the overhead of repeated TLS handshakes. The specification also defines:

  • Connection reuse — multiple queries on a single TLS session
  • Out-of-order processing — the server may respond to queries in any order (matching by DNS transaction ID)
  • Idle timeout — implementations should support configurable timeouts for idle connections

RFC 8310 (“Usage Profiles for DNS over TLS and DNS over DTLS”) extends the specification with two usage profiles:

Strict mode — the client authenticates the server using its TLS certificate (via SPKI pin or certificate chain validation). If authentication fails, the client refuses to send queries. This provides strong privacy but may fail if the server’s certificate changes unexpectedly.

Opportunistic mode — the client attempts DoT but falls back to plaintext DNS if the connection fails. This provides protection against passive eavesdroppers but not active attackers. It’s the “better than nothing” approach.

Port 853: Feature and Limitation

DoT’s use of a dedicated port is both its defining feature and its biggest operational challenge.

The Advantage

A dedicated port makes DoT traffic identifiable and manageable. Network administrators can:

  • Monitor DoT traffic volumes and patterns
  • Allow DoT to approved resolvers while blocking others
  • Enforce policy — permit encrypted DNS to the corporate resolver while blocking external DoT connections
  • Audit which clients are using encrypted DNS

This visibility is exactly what enterprise IT departments want. They can embrace encrypted DNS without losing control over which resolvers their clients use.

The Limitation

That same identifiability makes DoT easy to block. A firewall rule blocking port 853 disables DoT entirely. In countries that use DNS filtering for censorship, blocking port 853 is trivial — and many do.

This is the fundamental architectural difference between DoT and DoH:

  • DoT says: “I’m a DNS query, but I’m encrypted. You can see that I’m DNS, but you can’t see what I’m asking.”
  • DoH says: “I’m an HTTPS request. You can’t even tell that I’m DNS.”

For users in restrictive networks, DoH’s invisibility is a feature. For network administrators, DoT’s visibility is a feature. The two protocols serve different threat models.

DoT vs DoH: The Tradeoffs

The choice between DoT and DoH isn’t technical — both provide equivalent encryption strength. The difference is architectural and political.

Network Visibility

Aspect DoT DoH
Port 853 (dedicated) 443 (shared with all HTTPS)
Identifiable as DNS Yes No
Blockable Easy (block port 853) Very difficult (requires blocking HTTPS)
Enterprise-friendly Yes (manageable) Contentious (bypasses local control)

Protocol Overhead

DoH adds HTTP/2 framing on top of TLS, which means slightly more overhead per query. However, HTTP/2’s multiplexing and header compression largely offset this. In practice, latency differences between DoT and DoH are negligible for typical use.

DoT is arguably more efficient for high-volume resolver-to-resolver communication, where the HTTP layer adds no value. This is why some proposals for encrypted DNS between recursive resolvers and authoritative servers favor TLS-based approaches.

Deployment Model

DoH has been primarily deployed through browsers — application-level integration that bypasses the operating system’s DNS configuration. This is both its power (immediate deployment to billions of users) and its controversy (circumventing local network policy).

DoT has been primarily deployed through operating systems — system-level integration that affects all applications uniformly. This is more operationally sound (consistent behavior across applications) but slower to deploy (requires OS updates).

Adoption and Implementation

Android Private DNS

Android 9 (Pie), released in 2018, introduced Private DNS — a system-level DoT implementation. Users can configure it in three modes:

  • Off — plaintext DNS only
  • Automatic — attempts DoT with the current DNS resolver; falls back to plaintext if DoT isn’t supported (opportunistic mode)
  • Private DNS provider hostname — strict mode with a user-specified DoT server (e.g., dns.google or one.one.one.one)

This was the first major OS-level deployment of encrypted DNS, bringing DoT to over a billion devices. When Android users configure Private DNS, every DNS query from every app on the device goes through DoT.

systemd-resolved (Linux)

On Linux systems using systemd, systemd-resolved supports DoT natively. Configuration is straightforward:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes

The #cloudflare-dns.com suffix specifies the server name for TLS certificate validation (Server Name Indication). The DNSOverTLS=yes setting enforces strict mode; DNSOverTLS=opportunistic enables the fallback behavior.

Other Implementations

  • Stubby — a dedicated DoT stub resolver from the getdnsapi project, designed for desktop Linux and macOS
  • Unbound — a popular recursive resolver that supports DoT both as a client (to upstream resolvers) and as a server (for downstream clients)
  • knot-resolver — supports DoT with DNSSEC validation
  • iOS/macOS — Apple added DoT support in iOS 14 and macOS Big Sur through configuration profiles and the NEDNSSettingsManager API

Server-Side Deployment

For resolver operators, adding DoT support is relatively straightforward: configure TLS on port 853 with a valid certificate. Most major DNS software (Unbound, BIND 9.17+, Knot Resolver, PowerDNS Recursor) supports DoT natively.

The certificate management overhead is real but manageable — Let’s Encrypt certificates work fine, and automated renewal handles the lifecycle. The main operational concern is the additional TCP connections (compared to UDP) and the memory overhead of TLS session state.

DNS-over-DTLS

RFC 8094 defines DNS-over-DTLS — DNS over Datagram TLS, which uses UDP instead of TCP. This was designed to preserve DNS’s traditional UDP model while adding encryption.

In practice, DNS-over-DTLS has seen virtually no deployment. DTLS is more complex to implement than TLS, the lack of reliable transport complicates connection management, and the performance benefits over TLS (avoiding TCP overhead) are marginal given modern hardware and connection reuse patterns.

The protocol exists in the RFC ecosystem but is largely a historical footnote. DoT (over TCP/TLS) and DoH have absorbed the deployment energy that might have gone to DTLS-based solutions.

The Future of DoT

DoT occupies a pragmatic middle ground in the encrypted DNS landscape. It’s not as stealthy as DoH (and therefore less effective against censorship), but it’s more operationally transparent (and therefore more palatable to enterprises). It doesn’t have DoH’s browser-driven deployment momentum, but it has deep OS-level integration on the world’s most popular mobile platform.

The most likely future is coexistence: DoH dominant in browsers, DoT dominant in operating systems and enterprise deployments, and both gradually replacing plaintext DNS. The newest contender — DNS-over-QUIC — may eventually combine the best properties of both.

Key Takeaways

  • DoT wraps DNS in TLS on port 853 — simple, direct encryption of standard DNS messages
  • RFC 7858 defines the protocol; RFC 8310 adds strict and opportunistic usage profiles
  • The dedicated port makes DoT identifiable and manageable — enterprise-friendly but easy to block
  • Android Private DNS is DoT’s largest deployment, bringing encrypted DNS to over a billion devices
  • DoT vs DoH is an architectural choice, not a security one — both provide equivalent encryption
  • DoT favors network transparency; DoH favors censorship resistance — different threat models, different answers