Abstract

DNS-over-HTTPS (DoH, RFC 8484) has been deployed broadly across consumer browsers and mobile operating systems since Mozilla enabled it by default in Firefox in 2020, and its adoption has accelerated since. The dominant framing - DoH protects user privacy by encrypting DNS queries that were previously plaintext - is accurate but incomplete. DoH shifts the privacy model rather than eliminating surveillance risk, and for operators making resolver selection decisions at the enterprise or ISP level, the tradeoffs involve query log retention policies, anycast resolver visibility, and the concentration of DNS telemetry at a handful of large resolvers.

What DoH Actually Protects Against

DoH encrypts the DNS query between the client and the resolver over HTTPS, preventing on-path observers - including network operators, ISPs, and passive wiretap infrastructure - from seeing individual hostnames. This addresses a genuine threat model, particularly on untrusted networks. What it does not address is resolver-side visibility: the chosen resolver sees every query in plaintext. When Firefox defaults to Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8 resolvers, the browser moves DNS telemetry from the user’s ISP to those providers. Cloudflare’s published data retention policy (currently 25 hours for query logs with anonymization) is more privacy-protective than many ISP practices, but “resolver X has a better privacy policy than your ISP” is not the same as “DoH is private.”

Oblivious DNS-over-HTTPS and Its Current State

Oblivious DoH (ODoH, RFC 9230) separates query content from client identity by routing queries through an oblivious proxy. The client’s IP is visible to the proxy but not the resolver; the resolver sees the query but not the client’s IP. Apple and Cloudflare have operated an ODoH deployment since 2021, and it is supported in newer Apple platforms as an option. The operational complexity is higher - it requires a trusted proxy that does not collude with the resolver - and throughput is lower due to the extra hop and encryption overhead. For enterprises with strict DNS logging requirements or users in high-risk environments, ODoH represents a meaningful improvement over standard DoH, but adoption outside of Apple’s ecosystem remains limited as of early 2026.

Enterprise Resolver Selection Criteria

Enterprises deploying DoH internally face a different decision set than consumer users. Split-horizon DNS - where internal names resolve internally and external queries go to a recursive resolver - complicates DoH deployment, because browsers with hardcoded DoH resolvers bypass the local resolver entirely. The correct enterprise response is to either operate a local DoH-capable resolver (Unbound 1.13+ supports DoH, as does PowerDNS Recursor 4.7+) and advertise it via DHCP option 114 (DoH resolver hint, RFC draft), or to use DoH enforcement policies that redirect to an enterprise resolver. Leaving browsers to default to public DoH resolvers breaks split-horizon DNS and leaks internal hostnames to external resolvers - a security and compliance concern that is frequently underestimated.

The Concentration Problem

The broader concern for the DNS ecosystem is resolver concentration. With Chrome, Firefox, and mobile Safari all capable of DoH defaulting to a small set of public resolvers, a substantial fraction of global DNS queries routes through Cloudflare, Google, and NextDNS. This is operationally convenient but creates single points of failure and concentrates query telemetry. The IETF ADD (Adaptive DNS Discovery) working group is developing mechanisms for network operators to advertise trusted local resolvers to clients, reducing reliance on hardcoded defaults - the trajectory is toward a more distributed resolver ecosystem, but rollout across client platforms will take years.