Network Security
DNS over HTTPS
DNS over HTTPS (DoH) is a protocol that sends DNS queries and responses over an HTTPS connection rather than over the traditional unencrypted UDP transport, protecting DNS traffic from passive observation and modification by network intermediaries while introducing new architectural and operational considerations.
In plain terms
DNS over HTTPS (DoH) encrypts your DNS lookups inside normal web traffic, hiding which sites you are resolving from eavesdroppers. Good for privacy - though it can also bypass an organization’s DNS filtering if not managed.
Traditional DNS queries travel unencrypted over UDP port 53, visible to every observer along the path - a privacy weakness that DNS over HTTPS (DoH) addresses by wrapping DNS resolution inside standard HTTPS connections, making lookups indistinguishable from normal web traffic at the network layer. Defined in RFC 8484, DoH has become widely supported across browsers, operating systems, and DNS providers.
The motivating problem is the longstanding privacy weakness of traditional DNS. Standard DNS queries travel unencrypted over UDP port 53, visible to any network observer along the path. ISPs, local network operators, and adversaries can see which domains a user resolves, build profiles of browsing behavior, perform censorship through DNS, and potentially manipulate responses. DoH addresses observation and modification by wrapping DNS in TLS-protected HTTPS.
The protocol operates at HTTPS layer. Clients send DNS queries as HTTPS POST or GET requests to a DoH server, receive DNS responses in the HTTPS response body, and use standard TLS to protect the channel. DoH servers operate at well-known endpoints such as cloudflare-dns.com, dns.google, and many others. The use of HTTPS, rather than dedicated TLS for DNS like DoT, means DoH traffic looks identical to other web traffic at the network layer.
This indistinguishability from web traffic is the central architectural choice. DoH cannot be selectively blocked at the network layer without blocking all HTTPS traffic. This frustrates network-based DNS filtering and censorship, which is precisely the goal in many adoption scenarios. The same property complicates enterprise network management that depends on DNS visibility.
Adoption began with browsers. Firefox shipped DoH support enabled by default in some regions, with Cloudflare as the default resolver. Chrome enabled DoH when the user’s configured resolver supports it. Safari and Edge followed. Major operating systems including Windows 11 and recent macOS versions include DoH support. The browser-led adoption raised significant debate about enterprise control and parental control implications.
Operating system support complicates enterprise architectures. When browsers and operating systems perform DNS resolution through external DoH servers, internal DNS servers no longer see the queries. Internal DNS filtering, security monitoring, and split-horizon DNS configurations break. Enterprise environments have responded by configuring browser policies to use internal DoH endpoints, by blocking known public DoH endpoints, or by deploying DoH-aware proxies.
Centralization is a recurring concern. If most users resolve DNS through a small number of large public DoH providers, those providers gain substantial visibility into DNS activity worldwide. The privacy improvement against local network observers comes with a privacy concentration at the chosen resolver. Programs and users should consider this trade-off when selecting DoH providers.
Performance characteristics differ from UDP DNS. DoH typically has higher latency due to TLS handshake overhead, though connection reuse and HTTP/2 multiplexing reduce per-query cost. Modern implementations achieve performance close to UDP DNS for most queries. Cold connections still incur handshake latency that UDP DNS avoids.
DoH does not prevent traffic analysis based on domain identification. While DNS queries are encrypted, the subsequent connection to the resolved server reveals the destination through the IP address and, traditionally, the SNI in the TLS handshake. Encrypted Client Hello addresses the SNI exposure; without it, observers can still often infer the destination from the connection itself.
Enterprise DoH deployments support legitimate use cases. Organizations can operate their own DoH servers, configure managed devices to use them, and gain encryption of DNS in transit while preserving internal visibility and filtering. This pattern is increasingly common and combines DoH benefits with enterprise control.
DNS filtering products have adapted to DoH. Many enterprise DNS filtering services now offer DoH endpoints, allowing devices to use DoH while still applying filtering policies. Some products operate as DoH-aware proxies that intercept DoH traffic at the network edge. Programs should understand how their DNS filtering tools handle DoH and plan accordingly.
Comparison with DNS over TLS clarifies trade-offs. DNS over TLS (DoT) uses dedicated TLS on port 853, making it identifiable at the network layer and therefore manageable through network policy. DoH on port 443 is indistinguishable from web traffic. Both encrypt DNS in transit; they differ in network-layer visibility. Enterprise environments often prefer DoT for managed devices for the same reasons consumer adoption favored DoH.
Threat models supported by DoH include local network observers, ISPs, and some forms of censorship. DoH does not address threats from the DoH resolver itself, from observation of the subsequent connection, or from on-device malware. Programs should set realistic expectations about what DoH protects and what it does not. Operational logging at the client and at the DoH resolver enables both privacy and visibility goals. Client-side logging supports endpoint security operations. Resolver-side logging supports operational visibility and policy enforcement. Logging policies should reflect both privacy goals and operational needs.
Limits exist. DoH addresses transport privacy and integrity, not broader privacy goals such as preventing the destination provider from knowing who is connecting. It does not eliminate DNS-based attacks; it changes which attackers can perform them. It introduces enterprise management complexity that should be addressed explicitly rather than ignored.
A mature DoH deployment, whether consumer or enterprise, makes deliberate choices about resolver selection, manages the trade-offs around network visibility, and combines with other privacy and security tools to address the broader threat model. As DNS privacy continues to mature, DoH and related protocols including DoT, DoQ, and Encrypted Client Hello form a growing ecosystem of encrypted DNS and connection privacy that is reshaping how DNS works on the modern internet.