DNS over TLS: Dedicated Encrypted DNS Transport

While DNS over HTTPS (DoH) disguises DNS traffic as web browsing, DNS over TLS (DoT) takes a more direct approach—it wraps DNS queries in TLS encryption on a dedicated port (853). This design philosophy difference has significant implications for deployment, privacy, and network management.

DoT was standardized before DoH (RFC 7858, May 2016 vs. RFC 8484, October 2018) and represents the DNS community's initial solution to the DNS privacy problem. It answers the question: "How do we encrypt DNS with minimal protocol changes?" Rather than building on HTTP infrastructure, DoT simply adds TLS to the existing DNS-over-TCP transport.

DNS over TLS takes the simplest possible approach to encrypting DNS: establish a TLS connection to a DNS server, then send standard DNS queries over that encrypted connection. This mirrors how HTTPS works with HTTP—the underlying protocol remains unchanged, only wrapped in encryption.

Core protocol characteristics:

• Port 853 — Dedicated, well-known port for encrypted DNS (IANA assigned)
• TLS 1.2/1.3 — Standard TLS encryption; TLS 1.3 preferred for performance
• TCP transport — DoT uses TCP exclusively (no UDP option)
• Standard DNS messages — Wire format identical to RFC 1035 DNS-over-TCP
• Length-prefixed framing — Each DNS message preceded by 2-byte length field

Why port 853?

The dedicated port has advantages and disadvantages:

✅ Easy identification — Network operators can identify and manage DoT traffic
✅ No HTTP overhead — Simpler, more efficient than DoH
✅ Clear protocol separation — Distinct from web traffic

❌ Easy blocking — Firewalls can trivially block port 853
❌ Visible intent — Observers know you're using encrypted DNS
❌ Port may be restricted — Some networks only allow HTTP/HTTPS ports

Message framing:

DoT uses the same length-prefixed framing as traditional DNS-over-TCP:

1. Each DNS message is preceded by a 2-byte length field (network byte order)
2. Length indicates the size of the following DNS message in bytes
3. Multiple queries can be pipelined on a single connection
4. Responses may arrive out of order (matched by transaction ID)

This is identical to DNS-over-TCP, making DoT implementation straightforward—existing DNS-over-TCP code works with DoT by simply wrapping the socket in TLS.

Connection management:

RFC 7858 recommends persistent connections:

• Clients SHOULD reuse connections for multiple queries
• Clients SHOULD NOT pipeline more than a few outstanding queries (prevents HoL blocking)
• Servers SHOULD implement idle timeouts (recommended several seconds to minutes)
• Either party can close the connection at any time

DoT provides encryption, but encryption alone doesn't guarantee you're talking to the intended resolver. Authentication verifies the server's identity—crucial for preventing man-in-the-middle attacks where an attacker intercepts your encrypted DNS and decrypts it with their own certificate.

RFC 8310 defines two authentication modes:

Opportunistic TLS (unauthenticated encryption):

• Client accepts any valid certificate
• Encrypts traffic but doesn't verify server identity
• Protects against passive eavesdroppers
• Vulnerable to active MITM attacks
• Appropriate when authentication is impossible

Strict TLS (authenticated encryption):

• Client verifies server certificate validity
• Validates certificate chain to trusted CA
• Optionally verifies SPKI (public key) pin
• Protects against both passive and active attacks
• Recommended when resolver identity is known

SPKI (Subject Public Key Info) pinning:

For maximum security, clients can pin the resolver's public key. Instead of trusting any certificate from a valid CA, the client only accepts certificates containing a specific public key. This protects against:

• CA compromise (attacker obtains fraudulent certificate)
• Certificate misissuance (CA accidentally issues wrong certificate)
• Government coercion of CAs (forced certificate issuance)

How SPKI pinning works:

1. Obtain resolver's public key hash (SPKI pin) via trusted channel
2. Configure client with resolver hostname and SPKI pin
3. On connection, client extracts public key from certificate
4. Client computes hash and compares to configured pin
5. Connection only proceeds if pin matches

DANE (DNS-Based Authentication of Named Entities):

DANE uses DNSSEC to publish certificate information in DNS:

• TLSA records contain certificate/public key constraints
• DNSSEC signatures authenticate the TLSA records
• Client validates certificate against TLSA record

Challenge: Using DNS to authenticate DNS creates a chicken-and-egg problem—you need authenticated DNS to get TLSA records, but you're trying to establish authenticated DNS. Solutions involve trust-on-first-use or out-of-band bootstrapping.

DoT and DoH both encrypt DNS queries but differ significantly in their design philosophies, deployment characteristics, and suitability for different use cases. Understanding these differences helps choose the right protocol for specific scenarios.

Design philosophy difference:

• DoT: "Add encryption to DNS with minimal changes" — Uses dedicated port, standard DNS framing, straightforward implementation.

• DoH: "Make DNS indistinguishable from web traffic" — Uses HTTPS infrastructure, benefits from HTTP features, harder to block/detect.

The network operator perspective:

DoT and DoH have dramatically different implications for network operators:

With DoT:

• Operators can see encrypted DNS is in use (port 853 traffic)
• Operators can allow/block encrypted DNS as policy dictates
• Operators can redirect port 853 to internal encrypted resolver
• Security teams can monitor for unusual DoT usage patterns

With DoH:

• Operators cannot distinguish DNS from web traffic
• Blocking requires IP-level blocking (affects all services on that IP)
• Users can bypass network DNS policy entirely
• Security visibility is significantly reduced

The user perspective:

For privacy-focused users, the calculus is different:

DoT advantages:

• Slightly lower latency (no HTTP overhead)
• Simpler protocol may have fewer bugs
• Works well on mobile (Android native support)

DoH advantages:

• Cannot be selectively blocked
• Hides the fact that you're using encrypted DNS
• Works on restrictive networks (port 443 rarely blocked)

Performance is a critical consideration for encrypted DNS. Users won't accept significant latency increases for privacy. Understanding DoT's performance characteristics helps optimize deployments.

Latency breakdown:

Initial connection (cold start):

1. TCP handshake: 1 RTT
2. TLS 1.3 handshake: 1 RTT
3. DNS query/response: 1 RTT
4. Total: 3 RTT for first query

Subsequent queries (warm connection):

1. DNS query/response: 1 RTT
2. Total: 1 RTT per query

Connection resumption (TLS session ticket):

1. TCP handshake: 1 RTT
2. TLS resumption: 0-1 RTT (0-RTT with early data)
3. DNS query/response: piggybacked on TLS
4. Total: 1-2 RTT for resumed connection

Optimization strategies:

1. Connection pooling — Maintain persistent connections to avoid repeated TLS handshakes

2. TLS 1.3 — Reduces handshake from 2 RTT (TLS 1.2) to 1 RTT; supports 0-RTT resumption

3. 0-RTT early data — TLS 1.3 allows sending DNS query in resumption handshake (security caveats apply—replay possible)

4. TCP Fast Open — Sends data in SYN packet; reduces TCP handshake to 0 RTT for resumed connections

5. Connection warming — Proactively establish connections during idle time

6. Pipelining — Send multiple queries without waiting for responses (limited by head-of-line blocking)

Head-of-line blocking:

Unlike DoH with HTTP/2 multiplexing, DoT over TCP suffers from head-of-line blocking. If one query's response is delayed or lost, subsequent responses queue behind it. This is why RFC 7858 recommends limiting outstanding pipelined queries.

Comparison with UDP DNS:

Traditional DNS over UDP has inherent performance advantages:

• No connection establishment (stateless)
• Single RTT per query
• No TLS overhead

However, UDP DNS lacks reliability—lost packets require application-layer retries with exponential backoff. On lossy networks, DoT's TCP reliability can outperform UDP's retries.

Deploying DoT requires configuration at both client and server levels. The ecosystem has matured significantly, with native support in major operating systems and numerous resolver implementations.

Client deployment options:

Server-side DoT deployment:

Organizations can deploy their own DoT servers:

Popular DoT-capable resolvers:

1. Unbound — Full-featured recursive resolver with TLS frontend
2. Knot Resolver — Modern resolver with native DoT/DoH support
3. dnsdist — DNS load balancer with DoT termination/forwarding
4. CoreDNS — Kubernetes-native DNS with TLS plugins
5. BIND 9.17+ — Added DoT support in recent versions

Certificate management:

DoT servers need valid TLS certificates:

• Use Let's Encrypt for free, automated certificates
• Certificate must match hostname clients use for authentication
• Implement automated renewal (certbot + reload script)
• Consider certificate monitoring for expiration alerts

While DoT significantly improves DNS security, understanding its limitations and potential attack vectors is essential for proper implementation.

What DoT protects against:

1. Passive eavesdropping — Observers cannot read DNS query contents
2. Query manipulation — Encrypted queries cannot be modified in transit
3. ISP tracking — ISP cannot log which domains you query
4. Local network snooping — Café WiFi operators cannot see your DNS traffic

What DoT does NOT protect against:

Side-channel attacks:

Encrypted DNS can still leak information through side channels:

1. Message size analysis — Query length correlates with domain name length; response size reveals record count/type. Padding (RFC 7830) mitigates but doesn't eliminate.

2. Timing analysis — Resolution timing patterns reveal caching behavior, query frequency, and potentially visited domains.

3. Connection destination — IP address of DoT resolver is visible. Using well-known resolvers (1.1.1.1, 8.8.8.8) reveals you're using encrypted DNS.

4. TLS fingerprinting — Client TLS fingerprint may identify specific applications/configurations.

Downgrade attacks:

Strict DoT provides protection, but opportunistic mode is vulnerable:

• Attacker blocks port 853 → client falls back to unencrypted DNS
• Attacker intercepts connection → presents own certificate (accepted in opportunistic mode)
• User thinks DNS is encrypted but it's completely compromised

Mitigation: Always use strict mode with authentication when possible. If resolver identity is known, configure hostname verification and/or SPKI pinning.

DNS over TLS provides a straightforward approach to encrypting DNS queries using standard TLS on a dedicated port. Its design favors simplicity and network manageability over the censorship-resistance focus of DoH.

Let's consolidate the key concepts:

What's next:

Encrypted DNS protects against network-level threats, but DNS infrastructure faces many other attack vectors. The next page examines DNS attacks—the various ways attackers exploit DNS weaknesses, from cache poisoning and amplification attacks to DNS tunneling and hijacking. Understanding attack techniques is essential for implementing effective defenses.