DNS over TLS
DNS over TLS (DoT) is a communications protocol that encapsulates Domain Name System (DNS) queries and responses within Transport Layer Security (TLS)-encrypted TCP connections, providing privacy for DNS traffic by preventing eavesdropping and on-path tampering.[1] Specified in RFC 7858 and published in May 2016, DoT operates on TCP port 853, where clients initiate a TLS handshake before sending DNS messages prefixed with a two-octet length field, enabling secure stub-to-recursive resolver communication without altering the underlying DNS protocol.[1] This approach addresses vulnerabilities in traditional unencrypted DNS over UDP or TCP, as highlighted in RFC 7626, by leveraging TLS encryption to protect user queries from surveillance by network intermediaries like ISPs or attackers.[1] RFC 8310, published in March 2018, further defines usage profiles for DoT to guide implementation and deployment, including Opportunistic Privacy, which attempts encryption and authentication but falls back to unencrypted DNS if unavailable to ensure service continuity, and Strict Privacy, which mandates an authenticated, encrypted connection and fails otherwise to maximize protection against passive and active attacks.[2] These profiles support authentication mechanisms such as public key infrastructure (PKIX) validation using an authentication domain name or service provider key identifier (SPKI) pin sets, allowing clients to verify server identity securely.[2] DoT requires adherence to best current practices for TLS, including TLS 1.2 or higher, to mitigate risks like man-in-the-middle attacks, though it may face challenges from middleboxes that interfere with non-standard ports or long-lived TCP connections.[1] [2] Adoption of DoT has grown among public DNS resolvers to bolster end-user privacy, with Google Public DNS enabling support for encrypted TCP connections compliant with RFC 7858 starting in January 2019, emphasizing benefits like protection from spoofing and incremental deployment via opportunistic modes.[3] Cloudflare's 1.1.1.1 resolver also implements DoT alongside DNS over HTTPS (DoH), using it to encrypt queries and shield them from advertisers, ISPs, and malicious actors, though DoT's dedicated port makes it more identifiable in network traffic compared to DoH's use of standard HTTPS ports.[4] Other notable implementations include Quad9 and CleanBrowsing, which offer DoT for secure family filtering and threat blocking, contributing to broader ecosystem support in operating systems like Android and iOS where configurable.[4] While DoT enhances DNS security without requiring changes to authoritative servers, its reliance on TCP can introduce latency from connection setup and head-of-line blocking, prompting ongoing IETF discussions on optimizations and integration with emerging protocols like DNS over QUIC.[1]Introduction
Definition and purpose
DNS over TLS (DoT) is a network security protocol that encapsulates Domain Name System (DNS) queries and responses within Transport Layer Security (TLS) sessions to ensure encryption, authentication, and integrity of DNS communications between clients and recursive resolvers.[5] This approach secures the transport layer of DNS traffic, which traditionally operates over unencrypted UDP or TCP, thereby protecting the content of queries from unauthorized access.[5] The primary purpose of DoT is to safeguard DNS privacy and security by mitigating risks such as eavesdropping, tampering, and spoofing of queries in transit across networks.[5] It achieves this by encrypting the entire DNS message stream, preventing network observers—including Internet Service Providers (ISPs)—from viewing or logging the domains users are resolving, thus enhancing user privacy.[5] Additionally, server authentication via TLS certificates or pinned public keys verifies the resolver's identity, reducing the potential for man-in-the-middle attacks and DNS spoofing.[5] A key benefit of DoT is its provision of end-to-end encryption specifically for the "stub-to-recursive" segment of DNS resolution, complementing DNS Security Extensions (DNSSEC) by focusing on transport confidentiality rather than just data authenticity and integrity.[5] By default, DoT operates over TCP port 853, establishing a dedicated TLS-secured channel for DNS exchanges that maintains message integrity through query-response matching via DNS message IDs.[5]Historical context
The development of DNS over TLS (DoT) emerged in the early 2010s amid growing concerns over the privacy implications of unencrypted DNS traffic, which exposed users' browsing habits to eavesdroppers, including mass surveillance programs revealed by Edward Snowden's leaks in 2013. These disclosures, detailed in documents published by outlets like The Guardian, underscored the vulnerabilities of traditional DNS queries sent in plaintext over UDP port 53, prompting the Internet Engineering Task Force (IETF) to prioritize privacy enhancements. The IETF's recognition of pervasive monitoring as a systemic attack further catalyzed efforts to encrypt DNS communications. Initial proposals for encrypting DNS arose around 2014 within the IETF's DNS Operations (DNSOP) working group, where early drafts explored privacy considerations for DNS protocols.[6] This led to the formation of the DNS PRIVate Exchange (DPRIVE) working group in October 2014, chartered specifically to develop mechanisms for DNS confidentiality and integrity without altering the core protocol.[7] By 2015, DPRIVE had produced initial drafts outlining DoT as a method to tunnel DNS over TLS, building on existing encryption standards to address both passive surveillance and on-path attacks.[8] Key milestones included the publication of RFC 7858 in May 2016, which formalized DoT as a proposed standard for encapsulating DNS messages in TLS over TCP port 853, authored by researchers from USC/ISI, Verisign, and ICANN.[1] This was followed by RFC 8310 in March 2018, which provided usage recommendations through "strict" and "opportunistic" privacy profiles to guide implementation and balance security with compatibility.[9] Adoption accelerated post-2016, with integration into major operating systems and browsers by 2019–2020; for instance, Android 9 (Pie) introduced native DoT support in 2018. In 2025, regulatory momentum grew with the European Union's launch of DNS4EU, a privacy-focused resolver infrastructure supporting encrypted DNS to enhance data sovereignty and compliance with GDPR principles.[10]Technical foundations
DNS basics and vulnerabilities
The Domain Name System (DNS) functions as the Internet's distributed directory service, enabling the translation of human-readable domain names, such as example.com, into numerical IP addresses that computers use to locate resources. This process relies on a hierarchical architecture where user devices employ stub resolvers—simple clients integrated into operating systems—to initiate queries, which are then handled recursively by resolvers that iteratively consult root name servers, top-level domain (TLD) servers, and finally authoritative name servers holding the definitive records for specific domains.[11][12][13] In standard operation, DNS primarily uses the User Datagram Protocol (UDP) on port 53 for its low overhead in transmitting short queries and responses, reverting to Transmission Control Protocol (TCP) on the same port for larger payloads exceeding 512 bytes. All DNS messages are sent in plaintext, lacking any built-in encryption or authentication, which exposes them to interception and manipulation by anyone on the network path, including man-in-the-middle attacks that can redirect traffic or insert false information.[14][15][16] This unencrypted design introduces several critical vulnerabilities. Eavesdropping allows intermediaries, such as Internet Service Providers (ISPs), to log queries and infer user behavior, including visited websites and search patterns, compromising privacy without user consent. Injection and spoofing attacks exploit the lack of verification; a prominent example is the 2008 Kaminsky vulnerability (CVE-2008-1447), where attackers could predict transaction IDs and forge authoritative responses to poison resolver caches, enabling widespread redirection to malicious sites across the Internet. DNS blocking facilitates censorship by tampering with responses at the resolver level to deny access to targeted domains, as seen in various national filtering regimes that inject false errors for prohibited content. Additionally, open DNS resolvers can be abused in amplification attacks during distributed denial-of-service (DDoS) incidents, where attackers send spoofed small queries that trigger disproportionately large responses directed at victims, overwhelming networks with traffic multiples of the original request size.[17][18][19] DNS handles an immense volume of traffic; for example, DNSFilter's network processes about 170 billion queries daily as of 2025, underscoring its foundational role in Internet activity.[20] Despite growing awareness, studies show that the majority of this traffic remains unencrypted; for example, a 2024 analysis of mobile application DNS usage found 76.5% of queries still transmitted in plaintext, leaving them susceptible to the aforementioned risks. While extensions like DNSSEC address data validation through cryptographic signatures to ensure response authenticity and integrity, they provide no protection for the confidentiality of queries in transit.[21][22]TLS integration
DNS over TLS (DoT) utilizes Transport Layer Security (TLS) version 1.2 or higher as its underlying encryption protocol, with version 1.3 recommended to ensure perfect forward secrecy through ephemeral key exchanges.[1][3] TLS facilitates mutual authentication, though server authentication is mandatory via X.509 certificates, while client authentication remains optional.[1] This integration leverages standard TLS mechanisms without introducing any new cryptographic primitives, relying instead on established algorithms for key exchange, encryption, and authentication.[1] In terms of protocol integration, DNS messages are encapsulated within TLS records over a TCP connection on port 853, prefixed by a two-octet length field to delineate message boundaries.[1] The client includes the server's hostname in the Server Name Indication (SNI) extension during the TLS handshake, enabling certificate validation against that name; for enhanced security profiles, well-known service names such as "_dns._tcp.example.com" can be used in conjunction with DNS-based Authentication of Named Entities (DANE) for pinning public keys via TLSA records.[1][9] This wrapping ensures that the plaintext DNS queries and responses are protected at the transport layer, seamlessly adapting TLS's record-oriented structure to the variable-length nature of DNS packets.[1] The security properties of DoT are primarily inherited from TLS, including confidentiality through symmetric encryption, integrity via authenticated encryption with associated data (AEAD) modes or Hash-based Message Authentication Codes (HMAC), and protection against replay attacks through sequence numbering in the TLS record layer.[1] These features address DNS vulnerabilities like eavesdropping and tampering without requiring modifications to the core DNS wire format.[1] Performance considerations in DoT arise mainly from the TLS handshake, which introduces an initial latency overhead of approximately two round-trip times (RTTs) beyond the TCP connection setup, typically equating to 100-200 ms in average network conditions.[1] This overhead is mitigated through TLS session resumption mechanisms, such as session tickets defined in RFC 5077, allowing subsequent connections to reuse cryptographic parameters and reduce handshake time to one RTT or less.[1] Additionally, persistent TCP connections enable multiplexing multiple DNS queries over a single TLS session, further amortizing the setup cost.[1]Protocol details
Specification and standards
DNS over TLS (DoT) is formally specified in RFC 7858, published in May 2016 by the Internet Engineering Task Force (IETF). This document defines the protocol for encapsulating DNS messages within Transport Layer Security (TLS) to enhance privacy by encrypting DNS traffic between clients and recursive resolvers. It mandates the use of port 853 for DoT connections over TCP, employs stream semantics where DNS messages are prefixed with a two-octet length field as per RFC 1035, and outlines error handling procedures, including client retries upon connection failures and treatment of authentication errors as non-recoverable in certain profiles.[1] Supporting RFCs provide additional guidelines and updates to the core specification. RFC 8310, published in March 2018, establishes usage profiles for DoT, including Strict Privacy (which requires encrypted and authenticated connections) and Opportunistic Privacy (which allows fallback to unencrypted DNS), along with authentication mechanisms such as public key pinning and certificate validation. RFC 9461, published in November 2023, extends service binding mappings via DNS records to indicate support for encrypted transports like DoT, enabling better discovery of compatible servers. As of November 2025, no specific errata or extensions addressing post-quantum cryptography have been issued for DoT, though general TLS advancements incorporate hybrid post-quantum key exchange options. The IETF's DNS PRIVate Exchange (DPRIVE) Working Group, now concluded, developed these standards to address DNS privacy concerns. It specified TLS profiles requiring implementations to support TLS 1.2 or later, with mandatory cipher suites aligned to best practices, such as TLS_AES_128_GCM_SHA256 for TLS 1.3 sessions to ensure forward secrecy and integrity. Compliance criteria for DoT implementations emphasize robust security. Servers must support TLS 1.3 as the preferred version, following recommendations in RFC 9325 for secure TLS usage, and enable session resumption for performance. Clients verify server identity through Subject Public Key Info (SPKI) pinning for strict authentication or traditional Certificate Authority (CA) trust chains, with failure resulting in connection termination to prevent man-in-the-middle attacks.Operational mechanics
DNS over TLS (DoT) operates by encapsulating standard DNS messages within a Transport Layer Security (TLS) tunnel to ensure privacy and integrity during transmission. The process begins with session establishment, where a client initiates a TCP connection to the DNS server on port 853, as required for DoT communications.[1] Once connected, the client performs a TLS handshake to negotiate encryption parameters and authenticate the server, typically using X.509 certificates or Strict Privacy Profiles with Subject Public Key Info (SPKI) pinsets to verify the server's identity and prevent man-in-the-middle attacks.[1] Upon successful handshake completion, the TLS session is established, and subsequent DNS queries are transmitted as encrypted application data over this persistent connection.[1] The query-response flow in DoT involves serializing DNS messages—such as those requesting A or AAAA resource records—by prefixing each with a two-octet length field indicating the message size, per the DNS wire format.[1] These prefixed messages are then sent over the TLS-secured TCP stream, enabling efficient multiplexing of multiple queries and responses without the need for separate connections.[1] DoT supports pipelining, allowing clients to dispatch several queries in sequence without awaiting individual responses, which reduces latency compared to issuing one query at a time over non-persistent links.[1] The server processes these queries in order and returns corresponding responses, also prefixed with length fields, all within the encrypted TLS channel to protect against eavesdropping and tampering.[1] Error handling in DoT integrates both TLS-level and DNS-specific mechanisms. For transport or cryptographic issues, such as invalid certificates or protocol violations, the TLS layer generates alerts to close or renegotiate the connection securely.[1] DNS resolution errors, including SERVFAIL for server failures or NXDOMAIN for non-existent domains, are conveyed back to the client as standard DNS response messages encapsulated in encrypted TLS data, preserving privacy even in failure cases.[1] Connection management emphasizes efficiency and reliability for ongoing sessions. Clients and servers are encouraged to reuse established TLS connections for multiple queries rather than terminating them immediately after each exchange, with implicit keep-alives maintained through periodic data flow to prevent timeouts.[1] If a DoT session fails—due to connection refusal or handshake errors—clients may fall back to traditional unencrypted DNS over port 53 as a temporary measure, though this is discouraged to avoid exposing queries to surveillance, and clients should track such failures to retry DoT later.[1]Implementations
Server software
BIND, the widely used open-source DNS server developed by the Internet Systems Consortium (ISC), added native support for DNS over TLS (DoT) in version 9.18.0, released in January 2022.[23] This enables BIND to accept encrypted queries on a dedicated TLS listener, enhancing privacy for recursive and authoritative resolutions without requiring external proxies like stunnel for earlier versions. Support continues in subsequent releases, including BIND 9.20 as of 2025.[24] Unbound, a validating recursive caching resolver from NLnet Labs, has supported incoming DoT connections since version 1.7.1 in July 2018, functioning effectively as a stub or full recursive server for encrypted DNS traffic.[25] PowerDNS Authoritative Server, maintained by PowerDNS.COM B.V., does not have native built-in support for incoming DoT queries; encryption is typically handled via front-end tools like DNSdist, which added DoT in version 1.4.0 in 2019.[26] Knot Resolver, developed by CZ.NIC, provides native DoT server capabilities since version 1.1.0 in 2016, optimized for recursive setups with modular policy-based configurations.[27] Commercial solutions include BlueCat Networks' DNS appliances, formerly Nominum, which integrate DoT support within their BDDS (BlueCat DNS/DHCP Server) platforms based on BIND, enabling enterprise-grade encrypted authoritative and recursive services.[28] Configuring DoT on these servers typically involves enabling a TLS listener on the standard port 853, as defined in RFC 7858. Administrators must generate or obtain TLS certificates—either self-signed for internal use or issued by a trusted certificate authority (CA) for broader validation—and specify them in the server configuration files. Access control is enforced via ACLs (access control lists), such as BIND'sallow-query directive or Unbound's access-control options, to restrict DoT queries to authorized clients and prevent unauthorized access.[29]
Unique features include BIND's view mechanism, which allows administrators to define separate logical environments for DoT-only zones, isolating encrypted traffic from plain DNS responses based on client source or protocol.[30] Unbound offers caching optimizations tailored for encrypted queries, such as adjustable message and RRset cache sizes (e.g., msg-cache-size: 100m and rrset-cache-size: 200m) to balance memory usage and query performance under TLS overhead.[31]
Client software
Client software for DNS over TLS (DoT) enables devices and applications to initiate encrypted DNS queries to supportive resolvers, typically on port 853, enhancing privacy by preventing interception of unencrypted DNS traffic.[32] At the operating system level, Android has supported DoT since version 9, released in 2018, through its Private DNS setting, which allows users to specify a hostname for an encrypted resolver and applies the configuration system-wide.[33] iOS introduced DoT support starting with version 14 in 2020, requiring the installation of a configuration profile to enable encrypted DNS for both Wi-Fi and cellular networks, though it prioritizes DNS over HTTPS (DoH) in some scenarios.[34] Windows 11, launched in 2021, includes native DoT capabilities via DNS settings in the Network & Internet configuration, where users can enable encryption for specified resolvers, with support expanding through updates like version 22H2.[35] Browser integrations for DoT remain limited compared to DoH. Firefox, since version 67 in 2019, offers configurable secure DNS primarily via DoH, but can leverage OS-level DoT configurations for broader encryption without native DoT implementation.[36] Chrome, starting with version 83 in 2020, supports secure DNS with a fallback mechanism that relies on OS DoT where available, though its primary focus is DoH for direct resolver queries.[37] Safari provides limited DoT support, depending entirely on macOS or iOS system profiles installed since macOS Big Sur (2020) to route encrypted queries, as the browser itself does not handle DoT natively.[38] For developers, the getdns API offers a modern asynchronous interface to implement DoT in applications, supporting flexible transport options including TLS encryption for DNS queries as per RFC 7858.[39] Complementing this, Stubby, developed under the getdns project, serves as a lightweight local DoT stub resolver that forwards queries from clients to upstream resolvers over TLS, configurable via YAML files for multiple upstreams.[40] DoT client setup typically involves specifying the resolver's IP address and port 853, such as 1.1.1.1:853 for Cloudflare's service, to establish the TLS connection.[32] Enabling strict mode ensures queries only succeed over authenticated TLS, rejecting unencrypted fallbacks to prioritize security, while opportunistic mode allows reversion to plain DNS on port 53 if TLS fails, balancing reliability and privacy.[41] Fallback policies can be tuned in client configurations, such as in systemd-resolved or Stubby, to retry unencrypted DNS after TLS timeouts, though strict configurations are recommended for high-privacy environments.[3]Deployment and services
Public resolvers
Public DNS resolvers supporting DNS over TLS (DoT) provide encrypted query resolution on port 853, enhancing privacy and security for users worldwide. These services operate on anycast networks to ensure low latency and high availability, often incorporating additional features like content filtering and threat blocking. Cloudflare's 1.1.1.1 resolver launched DoT support in April 2018, offering variants such as 1.1.1.2 for malware blocking and 1.1.1.3 for family-friendly filtering that blocks adult content.[42][43] Its global anycast network spans over 300 cities, minimizing latency through proximity routing.[32] Google Public DNS at 8.8.8.8 introduced DoT in January 2019, emphasizing high availability via a distributed infrastructure.[3][44] It includes DNSSEC validation by default to verify response authenticity.[45] Quad9's 9.9.9.9 resolver, operated by the non-profit Quad9 Foundation, enabled DoT in 2017 and focuses on blocking malware and phishing domains using threat intelligence feeds.[46][47] Its network covers over 260 locations in more than 115 countries for broad geographic reach.[48] Other notable public DoT resolvers include CleanBrowsing, which provides security filters to block phishing and malware without adult content restrictions, and AdGuard DNS, centered on ad and tracker blocking.[49][50] Mullvad DNS, updated in 2025 to reinforce its strict no-logging stance, supports DoT with options for ad, tracker, and malware blocking.[51][52] Key features among these resolvers vary in logging policies and coverage, as summarized below:| Resolver | Logging Policy | Geographic Coverage | Key Features |
|---|---|---|---|
| Cloudflare | Query data retained up to 24 hours, then fully anonymized; no IP logging.[53] | 300+ cities globally via anycast. | Family filtering, low-latency anycast. |
| Google Public | Queries logged 24-48 hours for security, then anonymized (no permanent PII).[54] | Global anycast network. | DNSSEC validation, high availability. |
| Quad9 | No IP storage; data processed and forgotten immediately (true anonymization).[55] | 260+ locations in 115+ countries. | Malware/phishing blocking, non-profit. |
| CleanBrowsing | Configurable retention (no logs option for free tiers); minimal PII collection.[56] | Global via anycast. | Security filters for threats. |
| AdGuard DNS | Aggregated metrics only; raw queries up to 90 days for private setups, limited for public. | Global distribution. | Ad/tracker blocking. |
| Mullvad DNS | No activity logs, including DNS queries.[52] | Global anycast. | No-logging emphasis, content blocking. |