# DNS over HTTPS (DoH)
DNS over HTTPS (DoH) is a protocol defined in RFC 8484 that encrypts DNS queries by sending them over HTTPS connections to a DoH-compatible resolver. This prevents eavesdropping and manipulation of DNS traffic by on-path attackers, ISPs, and network operators, while blending DNS traffic with regular HTTPS traffic to make it indistinguishable from normal web browsing.
DoH emerged as a response to the fundamental privacy weakness in traditional DNS resolution. Standard DNS queries travel in plaintext, exposing every website visit, API call, and cloud service lookup to anyone monitoring network traffic. This visibility enables ISP tracking, government surveillance, corporate espionage, and attacker reconnaissance. By encrypting DNS queries within HTTPS, DoH eliminates this exposure while maintaining full compatibility with existing DNS infrastructure.
The protocol represents a significant shift in how DNS traffic is handled on the modern internet. Unlike DNS over TLS (DoT), which uses a dedicated port and remains identifiable as DNS traffic, DoH queries are indistinguishable from standard HTTPS requests. This design choice has profound implications for network visibility, enterprise security controls, and the balance between user privacy and organizational oversight.
DoH sits at the center of ongoing debates about internet governance, user privacy, and enterprise security architecture. Major browser vendors have embraced DoH as a privacy enhancement, while enterprise security teams view it as a blind spot that complicates threat detection and policy enforcement. Understanding DoH requires grasping both its technical mechanics and its broader implications for network security postures.
DoH operates by encapsulating DNS queries within standard HTTP requests sent to a DoH-compatible resolver. The process begins when a client application (typically a web browser) needs to resolve a domain name. Instead of sending a plaintext DNS query over UDP port 53, the client constructs an HTTPS request to a DoH resolver endpoint.
The DNS query is formatted as a binary message according to RFC 1035 standards, then embedded into an HTTP request using one of two methods. The GET method encodes the DNS query as a base64url parameter in the URL, while the POST method places the binary DNS message directly in the HTTP request body with the content type "application/dns-message." Most implementations prefer POST for efficiency, as it avoids URL length limitations and reduces cache visibility.
A typical DoH query follows this flow: the client establishes a TLS connection to the resolver on port 443, sends an HTTP request containing the DNS query, and receives an HTTP response containing the DNS answer. Because the entire exchange occurs over HTTPS, network observers see only encrypted traffic to what appears to be a standard web server. The resolver endpoint typically uses the path "/dns-query" but this is not mandated by the specification.
DoH leverages HTTP/2 multiplexing capabilities, allowing multiple DNS queries to be sent concurrently over a single TLS connection. This reduces latency compared to establishing separate connections for each query. Connection reuse further improves performance by avoiding repeated TLS handshakes. Advanced implementations support HTTP/3 over QUIC for even lower latency and better performance over unreliable networks.
Popular DoH resolvers include Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9). Each provides DoH endpoints accessible via standard URLs. For example, Cloudflare's DoH service accepts queries at https://1.1.1.1/dns-query, while Google uses https://dns.google/dns-query. These services typically offer both recursive resolution and additional security features like malware blocking and content filtering.
Browser implementation varies by vendor. Firefox was the first major browser to enable DoH by default in the United States, using Cloudflare as the default resolver. Chrome implements DoH with automatic discovery, attempting to upgrade to DoH if the system's configured DNS resolver supports it. Edge follows a similar pattern, while Safari has implemented DoH support without enabling it by default.
DoH can be configured at multiple levels: individual applications, operating systems, or network infrastructure. Application-level configuration provides the most user control but can create inconsistent behavior across different programs. Operating system configuration affects all applications but requires administrative privileges. Network-level configuration through captive portals or DHCP options can signal DoH availability to clients automatically.
Enterprise DoH deployment typically involves internal resolvers that combine encryption with organizational DNS policies. These internal DoH servers maintain corporate filtering rules, threat intelligence integration, and logging capabilities while providing the privacy benefits of encrypted DNS. Organizations may also deploy DoH proxies that intercept and decrypt DoH traffic for inspection before forwarding queries to upstream resolvers.
DoH traffic analysis reveals several distinctive patterns despite encryption. Request timing, frequency, and destination can provide information about user behavior and potential security incidents. Large enterprises implement DoH monitoring by tracking connection patterns to known public DoH resolvers and analyzing HTTP metadata that remains visible even when request contents are encrypted.
DoH fundamentally alters the security and privacy dynamics of enterprise networks by removing DNS visibility that organizations have relied on for decades. Traditional network security architectures assume DNS traffic is visible and controllable, enabling real-time threat detection, policy enforcement, and incident response. When browsers bypass corporate DNS infrastructure through encrypted DoH connections to external resolvers, these security controls become ineffective.
The business impact manifests in several critical areas. Content filtering systems that rely on DNS blocking cannot intercept queries sent via DoH to external resolvers. Data exfiltration detection systems lose visibility into DNS tunneling attacks that encode stolen data in DNS queries. Threat hunting operations lose the ability to identify command and control communication through DNS analysis. Compliance frameworks that require network monitoring face gaps when DNS traffic becomes encrypted and external.
Malware increasingly leverages DoH for covert communication channels. Advanced persistent threat groups use DoH to blend command and control traffic with legitimate browser requests, making detection significantly more difficult. The encrypted nature of DoH requests prevents deep packet inspection systems from analyzing query contents, while the use of legitimate DoH providers makes IP-based blocking impractical.
The shift to DoH also impacts incident response capabilities. Security teams investigating breaches traditionally analyze DNS logs to understand attacker behavior, identify compromised systems, and trace lateral movement. DoH queries sent directly from browsers to external resolvers bypass internal logging systems, creating blind spots in forensic analysis. This limitation becomes critical during ransomware incidents where DNS analysis helps identify attack vectors and scope.
Common misconceptions about DoH include the belief that it provides complete anonymity and that it cannot be monitored or controlled. DoH encrypts query contents but does not hide connection metadata, timing patterns, or destination IP addresses. Network administrators retain several options for DoH management, including blocking access to known DoH resolvers, requiring internal DoH servers, or implementing TLS inspection to decrypt and analyze DoH traffic.
The performance implications of DoH vary by implementation and network conditions. While HTTP/2 multiplexing and connection reuse can improve efficiency, the HTTPS overhead adds latency compared to traditional DNS. Organizations with optimized internal DNS infrastructure may experience slower resolution times when browsers switch to external DoH resolvers. However, users on networks with slow or unreliable DNS may see improved performance with well-designed DoH services.
DoH adoption creates a tension between individual privacy and organizational security that requires careful balance. The protocol provides genuine privacy benefits by preventing ISP tracking and protecting users on untrusted networks, but it complicates security operations in managed environments. Successful DoH strategies acknowledge both perspectives and implement solutions that preserve privacy while maintaining necessary security controls.
CDA's approach to DoH centers on the principle that DNS visibility and user privacy are not mutually exclusive requirements. The Sovereign Data Protocol demands that organizations maintain control over their data flows while respecting user privacy rights. DoH implementation becomes a question of architectural design rather than an either-or privacy versus security decision.
Within the CDA Practice Domains Matrix, DoH primarily falls under Data Protection and Stewardship (DPS) with significant implications for Threat Intelligence and Detection (TID). DPS teams evaluate DoH policies during C-BUILD assessments, ensuring that DNS encryption strategies align with data sovereignty requirements without creating unacceptable security gaps. This involves analyzing current DNS traffic patterns, identifying critical security controls that depend on DNS visibility, and designing DoH implementations that preserve necessary monitoring capabilities.
TID domain teams address DoH during C-HARDEN missions by developing detection capabilities that work despite DNS encryption. This includes implementing DoH traffic analysis, establishing baselines for normal DoH usage patterns, and creating indicators of compromise that do not rely on plaintext DNS content. TID teams also evaluate DoH-based evasion techniques and develop countermeasures that maintain threat detection effectiveness.
CDA's methodology differs from conventional approaches that view DoH as either a privacy enhancement to be embraced or a security risk to be blocked. Instead, CDA treats DoH as a technical requirement that must be implemented within a sovereign data architecture. This means deploying internal DoH infrastructure that provides encryption benefits while maintaining organizational control over DNS policies, logging, and threat detection.
The SDP application to DoH emphasizes that DNS resolution decisions belong to the data owner, not external service providers or browser vendors. Organizations implementing SDP deploy DoH resolvers within their sovereign infrastructure boundaries, ensuring that DNS queries receive privacy protection without exposing internal network topology or user behavior to third-party providers. This approach maintains the privacy benefits that drive DoH adoption while preserving the security visibility that enterprise teams require.
CDA assessments evaluate DoH readiness across multiple dimensions: technical infrastructure capability, policy framework adequacy, and operational team preparedness. Technical assessments examine whether internal DNS infrastructure can support DoH endpoints and whether network monitoring tools can analyze encrypted DNS traffic effectively. Policy assessments review whether DNS governance frameworks address DoH scenarios and user privacy requirements. Operational assessments determine whether security teams have the skills and tools necessary to maintain threat detection capabilities in DoH environments.
The CDA position recognizes that DoH adoption is inevitable rather than optional, driven by browser vendor decisions and user privacy demands. Organizations that attempt to block DoH entirely will face increasing technical challenges as browsers implement more sophisticated DoH detection and fallback mechanisms. The sustainable approach involves embracing DoH while implementing it within architectures that preserve necessary security controls and data sovereignty principles.
• DoH encrypts DNS queries within HTTPS traffic, providing privacy benefits while complicating enterprise security monitoring and threat detection capabilities.
• Organizations cannot prevent DoH adoption but can implement internal DoH infrastructure that combines encryption with necessary security controls and data sovereignty.
• Malware increasingly uses DoH for covert communication, requiring security teams to develop new detection methods that do not rely on plaintext DNS analysis.
• Successful DoH strategies balance user privacy with organizational security by deploying sovereign DoH infrastructure rather than blocking external DoH services.
• Browser vendors will continue expanding DoH adoption, making organizational DoH readiness a technical requirement rather than a policy choice.
• DNS Security and Threat Detection • Browser Security Management in Enterprise Environments • Network Monitoring in Encrypted Traffic Environments • Privacy-Preserving Security Architecture • Sovereign DNS Infrastructure Design