RFC 7858 — DNS over TLS
Specification for DNS over Transport Layer Security (TLS) — encrypted DNS resolution using a dedicated TLS connection on port 853, providing confidentiality for DNS queries.
1. Introduction
▶DNS over TLS (DoT) provides encrypted DNS resolution by establishing a TLS session on a dedicated port (853). Unlike DoH, DoT uses a separate well-known port, making it easier to manage in enterprise networks while still providing confidentiality.
ISO 27001 Relevance: A.8.20 (Network Security) — encrypted DNS prevents eavesdropping on name resolution. A.8.21 (Security of Network Services) — securing DNS as a network service. A.8.24 (Use of Cryptography) — TLS for DNS transport.
2. Protocol Design
▶- Port: TCP 853 (well-known, IANA assigned)
- TLS version: MUST support TLS 1.2+, SHOULD use TLS 1.3
- DNS message format: Standard DNS wire format with 2-byte length prefix (same as DNS over TCP)
- Connection reuse: Persistent connections RECOMMENDED to amortize TLS handshake cost
Client Stub Resolver DoT Server (port 853) ┌────────┐ ┌──────────────┐ │ Query │── TLS 1.3 ──> │ Recursive │ │ Resolver│ port 853 │ Resolver │──> Upstream │ │<── TLS 1.3 ── │ │ └────────┘ └──────────────┘
3. Authentication
▶DoT supports two authentication modes:
- Opportunistic: TLS without server certificate verification — protects against passive eavesdropping but not MITM
- Strict: Server certificate validated against SPKI pin or CA — protects against both passive and active attacks (RECOMMENDED for A.8.24)
4. Security Considerations
▶- Enterprise deployment: DoT's dedicated port makes it easier to monitor and manage than DoH — RECOMMENDED for enterprise networks (A.8.16)
- Blocking: Port 853 can be firewalled, making DoT less censorship-resistant than DoH — but more transparent for network operators
- Connection padding: Consider padding to prevent traffic analysis of DNS queries
- DNSSEC: DoT protects transport confidentiality; DNSSEC (RFC 4033) provides response authenticity — use both