View source for DNS over TLS

{{Note|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.<ref name="rfc7858">[https://datatracker.ietf.org/doc/html/rfc7858 Z. Hu et al., "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, IETF, May 2016.]</ref><ref name="dot-wiki">[https://en.wikipedia.org/wiki/DNS_over_TLS "DNS over TLS", Wikipedia (accessed 2025-11-27).]</ref>

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.<ref name="rfc7858" />

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.<ref name="rfc8310">[https://datatracker.ietf.org/doc/html/rfc8310 S. Dickinson et al., "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, IETF, March 2018.]</ref>

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.<ref name="sac109">[https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-109-en.pdf ICANN SSAC, "SAC109: The Implications of DNS over HTTPS and DNS over TLS", 12 March 2020.]</ref>

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.<ref name="sac109" />

=== 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.<ref name="nsa-encrypted-dns">[https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF NSA, "Adopting Encrypted DNS in Enterprise Environments", 14 January 2021.]</ref><ref>[https://www.cisa.gov/news-events/alerts/2021/01/15/nsa-releases-guidance-encrypted-dns-enterprise-environments CISA, "NSA releases guidance on encrypted DNS in enterprise environments", 15 January 2021.]</ref>

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.<ref>[https://media.defense.gov/2025/Mar/24/2003675043/-1/-1/0/CSI-Selecting-a-Protective-DNS-Service-v1.3.PDF NSA & CISA, "Selecting a Protective DNS Service", April 2025.]</ref>

=== 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.<ref>[https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/ G. Huston, "DNSSEC and DNS over TLS", APNIC Blog, 20 August 2018.]</ref><ref name="dot-wiki" />

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.<ref name="sac109" /><ref>[https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf ICANN SSAC, "SAC123: SSAC Report on the Evolution of Internet Name Resolution", 15 December 2023.]</ref>

== 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.<ref>[https://blog.apnic.net/2022/09/02/doh-dot-and-plain-old-dns/ G. Huston, "DoH, DoT and plain old DNS", APNIC Blog, 2 September 2022.]</ref>
* 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.<ref name="dot-wiki" /><ref>[https://developers.google.com/speed/public-dns/docs/dns-over-tls Google Public DNS, "DNS-over-TLS" (accessed 2025-11-27).]</ref>

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]]

== References ==
{{reflist}}

[[Category:Glossary]]