Specification for DNS over Transport Layer Security (TLS)
updated by
- rfc-8310 — Usage Profiles for DNS over TLS and DNS over DTLS
Extracted elements (27)
Alternative ports for DNS over TLS MUST NOT be port 53, specifically to avoid complication in selecting use or non-use of TLS and to reduce the risk of downgrade attacks. Using port 853 as the well-known dedicated port clearly signals TLS intent.
An earlier draft used a STARTTLS-like upgrade approach with a 'TLS OK' EDNS(0) flag and a dummy STARTTLS query, allowing negotiation over port 53. This was abandoned because: (1) uncertainty about middlebox support for the EDNS(0) flag, (2) the TLS OK bit makes downgrade attacks easy and indistinguishable from broken middleboxes, and (3) the approach required an extra RTT for the dummy query. The well-known port approach was chosen for simplicity and security.
DNS over TLS uses TCP rather than a new transport because connection-oriented TCP simplifies ordering, reliability, and session management. Performance overhead from TCP and TLS setup is mitigated by connection reuse, pipelining, TCP Fast Open (RFC 7413), and TLS session resumption (RFC 5077).
DNSSEC and DNS over TLS are independent and fully compatible protocols solving different problems: DNSSEC provides response integrity, while DNS over TLS provides query/response privacy. Use of one does not diminish the need or usefulness of the other.
A DNS client desiring privacy via DNS over TLS MUST establish a TCP connection to port 853, unless mutual agreement exists to use another port. That alternative port MUST NOT be port 53.
A DNS server supporting DNS over TLS MUST listen for and accept TCP connections on port 853 by default, unless mutual agreement exists with clients to use a different port.
All DNS messages (requests and responses) in an established TLS session MUST use the two-octet length field described in Section 4.2.2 of RFC 1035.
Clients and servers MUST adhere to the TLS implementation recommendations and security considerations of BCP 195 (RFC 7525).
Clients and servers that keep idle connections open MUST be robust to termination of idle connections by either party. Clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries.
DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port designated for DNS over TLS, including after a failed TLS handshake.
DNS clients SHOULD remember server IP addresses that do not support DNS over TLS, including timeouts, connection refusals, and TLS handshake failures, and not request DNS over TLS from them for a reasonable period (such as one hour).
Implementations of the out-of-band key-pinned privacy profile MUST support SHA-256 (RFC 6234) hashing of the DER-encoded ASN.1 SPKI of an X.509 certificate, and MUST support representation of the fingerprint as a base64-encoded string (RFC 4648).
In the out-of-band key-pinned privacy profile, if a computed SPKI fingerprint does not match any configured pin, the client MUST treat the SPKI validation failure as a non-recoverable error.
Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TLS connection using the Message ID. If the response contains a Question Section, the client MUST also match QNAME, QCLASS, and QTYPE fields.
The first data exchange on the TCP connection for DNS over TLS MUST be the client and server initiating a TLS handshake using the procedure described in RFC 5246.
When using TCP Fast Open, the client and server MUST immediately initiate or resume a TLS handshake; cleartext DNS MUST NOT be exchanged. DNS servers SHOULD enable fast TLS session resumption (RFC 5077).
Clients and servers SHOULD NOT immediately close a connection after each response; instead, they SHOULD reuse existing connections for subsequent queries. Successful TLS negotiation indicates willingness of both parties to maintain idle, persistent connections.
Clients SHOULD minimize creation of new TCP connections by reusing a single TCP connection to the recursive resolver or by using a local DNS request aggregator (forwarder) that maintains a single DNS-over-TLS connection on behalf of multiple clients.
DNS clients SHOULD pipeline multiple queries over a TLS session, not waiting for an outstanding reply before sending the next query, following RFC 7766 Section 6.2.1.1.
In the out-of-band key-pinned profile, clients authenticate servers by matching SPKI Fingerprints analogously to RFC 7469 (HTTP Public Key Pinning). Client administrators SHOULD deploy a backup pin alongside the primary pin to facilitate key rollover without simultaneous client coordination.
Two usage profiles are defined: (1) Opportunistic Privacy Profile — provides encryption without server authentication, analogous to SMTP opportunistic security; and (2) Out-of-Band Key-Pinned Privacy Profile — requires server authentication via a pre-configured SPKI fingerprint pin set, providing strong privacy guarantees.
IANA registered port 853 with service name 'domain-s' in the Service Name and Transport Protocol Port Number Registry for both TCP and UDP. Description: 'DNS query-response protocol run over TLS/DTLS'. UDP is reserved for the proposed DNS-over-DTLS protocol.
Any DNS protocol interactions performed in the clear can be modified by a person-in-the-middle attacker. For this reason, clients MAY discard cached information about server capabilities advertised in cleartext.
DNS over TLS does not resist traffic analysis or side-channel leaks. A well-positioned attacker may glean details from message timings and sizes. Clients and servers MAY use the EDNS(0) Padding Option (RFC 7830) to mitigate privacy leakage, though simple padding alone may not be sufficient against sophisticated classifiers.
DNS over TLS is vulnerable to known TLS attacks such as person-in-the-middle and protocol downgrade; these are general TLS risks. Clients tracking servers known to support TLS can detect downgrade attacks. Depending on privacy profile, clients may try another server, continue without TLS, or refuse to forward the query.
Middleboxes may interfere with normal DNS resolution; use of a designated port (853) for DNS over TLS should reduce such interference. Clients that attempt TLS and fail may fall back to unencrypted DNS or wait and retry, depending on their privacy profile.
All DNS messages over a TLS session use the two-octet length field from RFC 1035 Section 4.2.2, prepended to each DNS message, identical to the DNS-over-TCP framing. Implementations SHOULD pass the length field and message to the TCP layer together in a single write to encourage single-segment transmission.