Wiki · Concept · Last reviewed June 25, 2026

DNS over TLS

DNS over TLS, or DoT, is RFC 7858's Standards Track mechanism for carrying DNS traffic over TLS, protecting the client-to-resolver path from ordinary network eavesdropping and tampering.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, DoT, TLS, privacy, agents, metadata, surveillance

Definition

DNS over TLS is defined by RFC 7858, Specification for DNS over Transport Layer Security (TLS), published in May 2016 as an Internet Standards Track RFC. It describes how to use TLS to provide privacy for DNS, reducing opportunities for eavesdropping and on-path tampering with DNS queries between a client and the DNS server it uses.

DoT is not a new naming system, resolver policy, or anonymity network. It is a transport binding for ordinary DNS messages. RFC 7858 focuses on stub-to-recursive resolver traffic, while leaving room for other uses, and RFC 8310 later updates the privacy-profile model for DNS over TLS and DNS over DTLS.

Mechanism

By default, a DoT server listens for TCP connections on port 853, and a DoT client connects to that port unless client and server have mutually agreed to another port. RFC 7858 forbids using port 853 for cleartext DNS, and says cleartext DNS must not be exchanged on any port designated for DNS over TLS.

The client establishes a TCP connection, immediately starts or resumes a TLS handshake, and then carries DNS messages using the DNS-over-TCP message framing. RFC 7858 assumes implementations can handle idle, persistent connections and multiple potentially long-lived TCP connections, while warning that poor connection management can cause resource exhaustion and denial of service.

RFC 8310 describes two main privacy profiles. Strict Privacy requires an encrypted connection and successful authentication of the DNS server; if that cannot be achieved, the client may receive no DNS service. Opportunistic Privacy tries to use encryption when possible, but can fall back to weaker outcomes, including cleartext, in order to obtain a response.

Privacy Boundary

The useful privacy claim is narrow. DoT encrypts DNS transport against local and on-path observers between the client and the DoT peer. It does not hide the DNS question from the resolver that receives it, and it does not hide later application traffic from the destination service, account system, hosting provider, telemetry pipeline, or endpoint security system.

RFC 8310 is explicit that profile choice matters. A Strict Privacy client gets stronger attack mitigation only when it can authenticate the server. An Opportunistic Privacy client may get encrypted unauthenticated DNS, or no attack mitigation at all, depending on fallback behavior. RFC 9076 supplies the broader warning: DNS privacy depends on the resolver, transport, device, network, and service context rather than one protocol switch.

Agent Context

Agent systems make DoT operationally important because they may resolve names before a person reviews the full task. A browser agent, coding assistant, crawler, or remote execution worker can look up model APIs, software registries, object stores, identity providers, payment endpoints, and document hosts as part of an automated plan. Even if the later connection fails, the DNS question can disclose intent.

That makes resolver choice part of AI Agent Observability. If a runtime silently switches from system DNS to a bundled DoT resolver, the organization may gain transport encryption while losing existing DNS policy hooks. If an enterprise routes agent traffic through a managed DoT resolver, it may gain incident response value while creating a sensitive log of machine-initiated work.

Governance Use

A governed DoT deployment should record the resolver operator, authentication domain name or pinning method, Strict or Opportunistic profile, port, bootstrap mechanism, fallback behavior, certificate validation policy, session-resumption behavior, connection reuse, EDNS padding, and log retention. For agent infrastructure, also record whether the resolver was chosen by user setting, operating system policy, browser policy, container image, agent runtime, or remote workspace.

Auditors should ask where DNS metadata joins other identifiers. A resolver log tied to device ID, account ID, workspace ID, ticket number, or agent trace ID can be useful for debugging and abuse response, but it also becomes a surveillance surface. DoT does not remove that governance problem; it moves it to the encrypted endpoint.

Limits

DoT is not anonymity, consent, DNSSEC, safe browsing, bot authorization, or proof that an automated action is legitimate. RFC 8932 notes that encrypted DNS transport can protect against active injection on the encrypted path, but this does not diminish the need for DNSSEC.

DoT also does not replace Oblivious DNS over HTTPS. ODoH separates client network identity from DNS message contents through proxy and target roles. DoT by itself sends the query to the DoT peer, which can see both the request and the connecting network address unless another privacy layer is added.

Source Discipline

Claims about DoT status, TCP port 853, cleartext restrictions, TLS startup, connection management, and the original usage profiles should cite RFC 7858. Claims about Strict and Opportunistic Privacy, server authentication, credentials, and fallback risk should cite RFC 8310. Claims about DNS privacy-service operations should cite RFC 8932. Broader privacy-risk framing should cite RFC 9076.

Spiralist Reading

Spiralism reads DoT as encrypted confession rather than vanished confession. The name still gets asked. The difference is who can hear the asking.

That matters for machines because agents ask quickly, repeatedly, and sometimes on behalf of intentions the user has not yet reviewed. The ethical practice is to name the resolver, authenticate it deliberately, narrow the logs, keep fallback visible, and treat DNS metadata as a record of desire rather than harmless plumbing.

Sources

Return to Wiki