DNS over TLS

For the technical specification, see RFC 7858.

DNS over TLS (DoT) is a method of performing DNS resolution over TLS, usually on a dedicated port (853). It encapsulates DNS queries and responses in an encrypted TCP/TLS session between clients and recursive resolvers, with the goal of protecting them from on-path monitoring or tampering while keeping DNS as a distinct protocol layer.

Compared to DNS over HTTPS (DoH), which integrates DNS into the Web stack, DoT is typically deployed by network and system operators as an “encrypted equivalent” of classic DNS, focusing on the path between stub resolvers and recursive resolvers.

Origins and Standardization

DoT emerged from the IETF’s work on DNS privacy in the DPRIVE Working Group, following the analysis of DNS surveillance risks in RFC 7626. RFC 7858 specifies how traditional DNS “wire format” messages are carried over TCP connections protected by TLS, using a dedicated port 853 for encrypted DNS between clients and recursive resolvers.

RFC 7858 was later profiled and updated by RFC 8310, which defines authentication and usage profiles for DNS over TLS and DNS over DTLS, including “strict” and “opportunistic” privacy modes and concrete guidance on certificate validation for resolvers.

From a governance perspective, these RFCs remain protocol-oriented: they define how to encrypt the stub-to-recursive channel, but are largely neutral about which entities operate the resolvers and how policy is applied.

Governance Aspects

Operator-Controlled Encrypted DNS

In contrast to application-driven DoH, DoT is usually configured and managed by the network or system operator. The SSAC highlighted this distinction in SAC109: The Implications of DNS over HTTPS and DNS over TLS: DoT tends to preserve the traditional model in which the operating system or network stack chooses a resolver, while DoH enables applications—especially browsers—to make independent resolver choices.

Because DoT uses a dedicated port and is often deployed by the same entities that already operated DNS infrastructure, it is generally seen as less disruptive to existing governance arrangements around resolver selection, logging, and accountability. However, it still changes expectations about visibility: on-path entities no longer see DNS contents between the client and its recursive resolver, even if they can still observe metadata such as IP addresses and timing.

Filtering and “Protective DNS”

DoT can be used to support both open-resolution and policy-enforced “protective DNS” services. Guidance from the U.S. National Security Agency (NSA) on encrypted DNS recommends that enterprise networks direct all DNS traffic—encrypted or not—to designated enterprise resolvers, and explicitly allows DoT as one of the transports for doing so.

In this model, DoT is not used to bypass network policy; instead, it protects DNS queries from exposure on untrusted local networks while preserving the ability of operators to apply filtering, logging, and incident response at the resolver. Later NSA and CISA documents on protective DNS treat DoT, DoH and DNS over QUIC as interchangeable encrypted channels that can all carry policy-enforced DNS traffic.

Relationship to DNSSEC and DNS Privacy Work

DoT is part of a broader set of technologies intended to strengthen DNS security and privacy. Whereas DNSSEC provides origin authentication and data integrity between authoritative servers and resolvers, DoT protects the confidentiality and integrity of queries and responses between clients and resolvers. The two are generally viewed as complementary rather than competing: DNSSEC secures the data itself, while DoT secures the transport path on part of the resolution chain.

Reports such as SAC109 and later SSAC work (for example, SAC123 on the evolution of Internet naming) treat DoT as one element in a larger shift toward encrypted transport, encrypted client hello (ECH), and alternative naming systems, all of which affect how much of DNS behaviour is visible to different actors in the Internet governance ecosystem.

DoT in Technical Community Discussions

DoT appears in technical and policy discussions as the “operator-friendly” encrypted DNS mechanism. Blogs and measurements from operators and Regional Internet Registries often contrast DoT and DoH:

• APNIC has described DoT as the initial standard response to DNS privacy concerns, with DoH coming later and raising additional questions about application-driven resolver choice.
• Cloudflare, Google and other large operators present DoT as the natural upgrade path for resolvers and stub resolvers that want encryption without changing the basic DNS architecture.

Within the ICANN community, DoT is usually discussed together with DoH and DoQ, with emphasis on how encrypted transports change resolver discovery, logging practices, and the practical role of access providers and enterprises in DNS governance, rather than on the specific cryptographic details.

See Also

• DNS over HTTPS
• DNS over QUIC

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

DNS over HTTPS

Internet Engineering Task Force

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).

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).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).

Domain Name System Security Extensions

Asia Pacific Network Information Centre