# DNS over TLS (DoT)
DNS over TLS (DoT) is a security protocol defined in RFC 7858 that encrypts DNS queries by wrapping them in a Transport Layer Security (TLS) connection on a dedicated port (853). Unlike DNS over HTTPS (DoH), which tunnels DNS queries through HTTPS traffic on port 443, DoT operates on a distinct port, making it identifiable and manageable at the network level while providing encryption and authentication for DNS communications.
The protocol emerged in response to a fundamental weakness in the Domain Name System: all traditional DNS queries travel in plaintext. When a user types "secure-bank.com" into their browser, the DNS query asking "what is the IP address for secure-bank.com" is visible to anyone monitoring network traffic. This visibility creates privacy concerns and security risks. Network operators can see every website a user visits. Attackers can intercept and modify DNS responses to redirect users to malicious sites. Governments can monitor and censor internet access by observing DNS queries.
DoT solves these problems by encrypting the entire DNS conversation between client and resolver. The encryption prevents eavesdropping on DNS queries and responses. The TLS authentication prevents man-in-the-middle attacks where attackers impersonate legitimate DNS resolvers. The integrity protection ensures that DNS responses cannot be modified in transit.
DoT fits into a broader ecosystem of DNS security protocols. DNSSEC provides cryptographic validation of DNS responses but does not encrypt the queries themselves. DoH provides similar encryption to DoT but tunnels DNS through HTTPS traffic. DNS over QUIC (DoQ) represents an emerging alternative that uses the QUIC transport protocol. Each approach makes different trade-offs between security, performance, and network visibility.
The protocol's design reflects a specific philosophical choice: DNS traffic should be encrypted but remain identifiable as DNS traffic. This makes DoT particularly suitable for enterprise environments where security teams need to control and monitor DNS behavior while protecting the privacy of individual queries.
DoT operates by establishing a TLS session between a DNS client and a recursive DNS resolver on TCP port 853. The process begins when a client application needs to resolve a domain name. Instead of sending a plaintext DNS query on port 53, the client initiates a TLS connection to a DoT-enabled resolver on port 853.
The TLS handshake proceeds exactly like any other TLS connection. The resolver presents its X.509 certificate, which must be valid and trusted by the client. The certificate should contain the resolver's hostname or IP address in the Subject Alternative Name (SAN) field. The client validates the certificate chain back to a trusted Certificate Authority. If certificate validation fails, the behavior depends on the client's configuration: opportunistic mode falls back to plaintext DNS, while strict mode rejects the connection entirely.
Once the TLS session is established, standard DNS wire format messages flow through the encrypted tunnel. The client sends DNS queries exactly as it would over plaintext DNS, but the entire payload is encrypted and authenticated by TLS. The resolver processes queries normally and returns responses through the same encrypted channel. From the resolver's perspective, DoT queries are functionally identical to plaintext queries once they are decrypted.
Connection management is critical for DoT performance. TLS has higher overhead than UDP-based plaintext DNS, so implementations typically maintain persistent connections rather than establishing a new TLS session for each query. A single TLS connection can carry multiple DNS queries and responses. TLS session resumption allows clients to reconnect quickly using cached session parameters, reducing the cryptographic overhead of repeated connections.
DoT supports both opportunistic and strict modes of operation. Opportunistic DoT attempts to establish an encrypted connection but falls back to plaintext DNS if the resolver does not support DoT or if the TLS connection fails. This mode prioritizes availability over security and provides protection against passive eavesdropping but not against active attacks that deliberately break the TLS connection. Strict DoT requires successful TLS establishment and certificate validation, providing stronger security guarantees but potentially reducing availability if DoT services are unreliable or blocked.
Real-world DoT implementations handle several practical challenges. Connection timeouts must be managed carefully because TCP connections can become stale, particularly on mobile devices that frequently change networks. Some implementations maintain multiple concurrent connections to different resolvers for redundancy and load balancing. Others implement connection pooling to reuse TLS sessions across multiple applications on the same device.
Enterprise DoT deployments often involve additional infrastructure considerations. Organizations may deploy DoT forwarders that accept encrypted queries from internal clients and forward them to upstream resolvers. These forwarders can apply local DNS policies, logging, and filtering while still providing encryption for the client-to-forwarder segment. Some enterprises use DoT selectively, encrypting external DNS queries while keeping internal DNS queries in plaintext for monitoring and troubleshooting purposes.
The protocol also supports various authentication models. Public DoT resolvers like Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) use certificates issued by public Certificate Authorities, allowing any client to validate their identity. Enterprise deployments may use private CAs or pinned certificates for additional security. Some implementations support authentication of clients to resolvers using client certificates, though this is less common due to the complexity of certificate management.
Performance characteristics vary significantly between implementations and network conditions. DoT typically has higher latency than plaintext DNS for the initial query due to the TLS handshake, but subsequent queries over the same connection may perform comparably to plaintext DNS. The persistent TCP connections used by DoT can actually provide better performance than UDP-based plaintext DNS in high-packet-loss environments because TCP handles retransmission automatically.
DoT addresses critical privacy and security weaknesses in the DNS infrastructure that supports all internet communication. Every website visit, email delivery, and API call begins with a DNS query. When those queries are unencrypted, they create a comprehensive record of user internet activity that is visible to internet service providers, network operators, and anyone monitoring network traffic.
The business impact extends beyond individual privacy concerns. Organizations face compliance requirements under regulations like GDPR, HIPAA, and various data localization laws that govern how personal information moves across networks. DNS queries can reveal sensitive business activities: which cloud services an organization uses, which vendors it communicates with, and which geographic markets it operates in. Unencrypted DNS queries can expose competitive intelligence and business relationships.
DoT's dedicated port provides operational benefits that distinguish it from DoH. Network security teams can identify DoT traffic, allowing them to implement policies that permit encrypted DNS to approved resolvers while blocking encrypted DNS to unauthorized or potentially malicious resolvers. This visibility enables organizations to maintain DNS security policies without sacrificing encryption. For example, an enterprise might configure firewalls to allow DoT connections only to internal resolvers and specific external resolvers that meet security requirements.
The protocol also supports defense-in-depth security strategies. Even when organizations use secure DNS resolvers and implement DNSSEC validation, DoT provides an additional layer of protection against network-based attacks. Attackers who compromise network infrastructure cannot observe or modify DNS queries protected by DoT, reducing the attack surface for DNS poisoning and surveillance.
However, DoT's visibility cuts both ways. The dedicated port makes DoT easy to block, and some internet service providers and national firewalls do exactly that. Organizations deploying DoT must account for network environments where port 853 is filtered. This has driven some organizations to prefer DoH, which is much harder to block because it uses the same port as normal web traffic.
DoT adoption faces several misconceptions. Some security teams worry that encrypted DNS will blind their security tools, but DoT actually provides better security visibility than plaintext DNS in many scenarios. DNS security tools can receive query logs directly from DoT resolvers rather than reconstructing them from network traffic, providing more complete and accurate data. The encryption protects against external eavesdropping while preserving the organization's ability to monitor its own DNS activity.
Another misconception is that DoT significantly impacts network performance. While the initial TLS handshake does add latency, persistent connections and modern TLS implementations minimize the performance impact for most use cases. The benefits of encrypted DNS typically outweigh the modest performance overhead, particularly as TLS performance continues to improve with newer protocol versions and cryptographic algorithms.
The failure consequences of improper DoT implementation can be significant. Misconfigured opportunistic DoT may fail silently, providing users with the illusion of encrypted DNS while actually falling back to plaintext queries. Poorly implemented strict DoT can break DNS resolution entirely when DoT services become unavailable. Organizations must test DoT deployments thoroughly and implement appropriate monitoring to ensure that encrypted DNS is working as intended.
CDA's approach to DNS over TLS centers on the Sovereign Data Protocol: "Your data lives where you decide. Period." DNS queries are data, and that data reveals intimate details about user behavior, business operations, and organizational relationships. Under SDP principles, organizations must control where that DNS data flows and who has access to it. DoT provides the technical foundation for DNS sovereignty, but only when deployed with careful attention to resolver selection and network architecture.
The Data Protection and Sovereignty (DPS) domain owns DoT implementation within the PDM framework because DNS queries represent a continuous stream of potentially sensitive data leaving the organization's control. Traditional plaintext DNS creates a data sovereignty violation: every DNS query flows to external resolvers where it can be logged, analyzed, and potentially monetized by third parties. DoT encryption is necessary but not sufficient for DNS sovereignty. Organizations must also carefully select DoT resolvers based on their data handling policies, geographic location, and legal jurisdiction.
CDA's methodology differs significantly from conventional DoT deployment guidance, which typically focuses on technical configuration and performance optimization. CDA begins with data classification and flow mapping. Where are DNS queries generated? What information do they contain? Where do they flow? Which resolvers have access to the query data? How long is the data retained? These questions drive technical decisions about resolver selection, connection policies, and monitoring implementation.
During C-BUILD campaigns, CDA operators evaluate DNS architecture through the lens of data sovereignty and operational control. A common finding is that organizations have implemented DoT encryption but continue to send queries to public resolvers operated by advertising companies or foreign governments. The encryption protects the queries in transit but does not address the fundamental sovereignty issue of external parties collecting comprehensive DNS logs.
CDA recommends a tiered DoT deployment model that balances sovereignty, performance, and availability. Internal DNS queries for organizational resources should resolve through internal DoT-enabled resolvers that never forward queries externally. External DNS queries should route through carefully selected DoT resolvers that align with the organization's data sovereignty requirements. This might mean using resolvers operated by trusted cloud providers within appropriate geographic regions, or deploying forwarding resolvers that apply organizational policies before querying upstream providers.
The Security Posture and Hygiene (SPH) domain intersects with DoT through DNS security policy enforcement. CDA treats DoT as an enabler for DNS security controls rather than a replacement for them. The protocol's dedicated port allows organizations to implement granular network policies: permit DoT to approved resolvers, log connection attempts to unauthorized DoT services, and block plaintext DNS entirely to enforce encryption requirements.
CDA's approach to DoT strict versus opportunistic modes reflects broader SDP principles. Opportunistic DoT that falls back to plaintext DNS creates a false sense of security and undermines data sovereignty. If DNS encryption is important enough to implement, it is important enough to enforce. CDA typically recommends strict DoT with careful attention to resolver redundancy and failover mechanisms.
This perspective challenges conventional wisdom that emphasizes DoT adoption over DoT control. Many organizations implement DoT by simply configuring client systems to use public DoT resolvers, treating it as a privacy enhancement rather than a data sovereignty decision. CDA recognizes that encrypted DNS queries flowing to external resolvers may actually create greater privacy risks than plaintext DNS in some threat models because the queries are concentrated in systems specifically designed to collect and analyze DNS data.
• DoT encrypts DNS queries using TLS on port 853, providing privacy and security while maintaining network visibility through its dedicated port, making it ideal for enterprise environments that need both DNS encryption and traffic control.
• Unlike DoH, DoT traffic is easily identifiable and can be selectively allowed or blocked, enabling organizations to enforce DNS security policies that permit encrypted queries only to approved resolvers.
• Proper DoT implementation requires strict mode with certificate validation to prevent fallback attacks, along with careful resolver selection based on data sovereignty requirements rather than just performance metrics.
• DNS queries represent a continuous data stream that reveals user behavior and business operations, making DoT a critical component of data sovereignty strategies under the Sovereign Data Protocol framework.
• Effective DoT deployment involves tiered architecture with internal resolvers for organizational resources and carefully vetted external resolvers for internet queries, rather than simply routing all DNS traffic to public DoT services.
• DNS Security and DNSSEC Implementation • Sovereign Data Protocol: Controlling Your Data Flow • Network Security Policy Enforcement • Enterprise DNS Architecture Design • Data Protection and Sovereignty Framework
• RFC 7858: Specification for DNS over Transport Layer Security (TLS). Internet Engineering Task Force, 2016.
• NIST Special Publication 800-81-2: Secure Domain Name System (DNS) Deployment Guide. National Institute of Standards and Technology, 2013.
• DNS Privacy Considerations (RFC 7626). Internet Engineering Task Force, 2015.
• Zhu, Liang, et al. "Connection-Oriented DNS to Improve Privacy and Security." 2015 IEEE Symposium on Security and Privacy, 2015.
• SANS Institute. "DNS Security: Defending the Domain Name System." SANS Reading Room, 2019.