RFC 7858

For implications on Internet governance, see DNS over TLS.

RFC 7858, Specification for DNS over Transport Layer Security (TLS), is an IETF standards-track RFC that defines DNS over TLS (DoT) as a way to run DNS over TCP connections in a protected manner. The goal is to provide confidentiality and integrity protection for DNS queries and responses between clients and recursive resolvers, particularly on the “last mile” between end users and their chosen resolver.

Background

DNS, as specified in RFC 1035, sends most queries in cleartext over UDP or TCP port 53, exposing them to interception, modification, and monitoring. Growing concern about DNS privacy, combined with the ease with which on-path devices can interfere with DNS traffic. As attention to pervasive monitoring increased, the IETF began work on encrypting DNS transport, resulting first in DNS over TLS and later in DNS over HTTPS (DoH) and DNS over QUIC (DoQ).

RFC 7858 addresses the segment between stub or forwarding resolvers and recursive resolvers, where user queries are most exposed. Subsequent work extended the approach to other parts of the DNS tree, such as “Authoritative DNS over TLS” (ADoT) between recursive and authoritative servers, but this is out of scope for RFC 7858 itself.

Protocol Overview

RFC 7858 specifies that a DNS server supporting DoT listens for TCP connections on the well-known port 853. When a client connects to this port, both sides expect to negotiate a TLS session and then exchange DNS messages over that encrypted channel.

DNS runs over TCP, with TLS layered on top. Once the TLS handshake completes, the client and server exchange standard DNS messages in “wire format” as defined in RFC 1035, without changing the DNS message structure. A single TLS session can carry multiple DNS queries and responses, and clients are encouraged to pipeline queries to amortize the cost of TCP and TLS handshakes. All traffic on port 853 is expected to be encrypted; mixing cleartext DNS and DoT on this port is discouraged, since it complicates configuration and security analysis.

The DoT server authenticates with a normal TLS server certificate. RFC 7858 gives initial guidance for authenticating resolvers, which is later updated and expanded by RFC 8310. The protocol is agnostic about the internal behavior of the recursive resolver. It specifies only the secure transport between client and resolver; cached resolution, forwarding, and communication with authoritative servers continue as in classic DNS.

Usage Profiles and RFC 8310

RFC 7858 introduces two high-level privacy profiles for DNS over TLS:

• Strict privacy: The client requires an authenticated TLS connection to a specific resolver. If TLS negotiation or authentication fails, the client treats this as a hard failure and does not fall back to cleartext DNS.
• Opportunistic privacy: The client attempts to use TLS when available but may continue with cleartext DNS if it cannot establish an encrypted channel.

These concepts are refined in RFC 8310, which focuses on authentication mechanisms and concrete usage profiles for DNS over TLS and DNS over DTLS. RFC 8310 describes how clients can use an “authentication domain name” for the resolver, how to validate its certificate, and which TLS parameters are appropriate for DNS traffic. It also formally updates RFC 7858 to shift detailed profile definitions into the newer document.

Deployment Models

RFC 7858 is written primarily for use between stub or forwarding resolvers running on end-user devices or customer-premises equipment; and recursive resolvers operated by ISPs, enterprises, or public DNS providers.

In practice, DoT is offered by a wide range of public resolvers. Cloudflare’s 1.1.1.1 service, for example, supports DoT on port 853 for IPv4 and IPv6 addresses and via the hostname one.one.one.one. Google Public DNS exposes DoT endpoints as well, documented with configuration examples for both strict and opportunistic profiles.

Security and Privacy Properties

By running DNS over TLS, RFC 7858 aims to protect the confidentiality and integrity of DNS traffic between client and resolver:

• An on-path observer between the two endpoints can no longer read or modify DNS payloads in the clear, although it may still see metadata such as IP addresses and timing information.
• The resolver is authenticated using the normal TLS server certificate model, which helps prevent active attacks such as spoofing and man-in-the-middle interception.
• Since DoT operates between the client and recursive resolver, it does not provide end-to-end encryption up to authoritative name servers; protection is hop-by-hop, and only where both endpoints support DoT.

The RFC also discusses performance considerations. Because DoT relies on TCP and TLS, naive implementations can introduce extra latency. RFC 7858 recommends the use of persistent connections, query pipelining, and modern TLS implementations to reduce overhead, and notes that long-lived sessions are particularly beneficial in high-query environments.

See Also

• RFC 8484
• RFC 9250

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

Internet Engineering Task Force

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

DNS over HTTPS

Internet Service Provider