Which DNS-over-HTTPS and DNS-over-TLS providers support client IP privacy for third-party resolvers?
Executive summary
Encrypted DNS via DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) is widely supported by major public resolvers—Cloudflare, Google, NextDNS and others—but encryption alone does not remove the client's IP address from the resolver's view; client-IP privacy for third‑party resolvers requires additional measures (anonymizing relays, DNS‑level partitioning, or specialized proxies) rather than just DoH/DoT endpoints [1] [2] [3] [4].
1. Major public DoH/DoT providers: encryption, not anonymization
Cloudflare and Google operate large, public DoH and DoT endpoints—Cloudflare documents DoT on 1.1.1.1 and associated addresses [1] and multiple sources note Cloudflare and Google serve the lion’s share of DoH traffic [5]; Google Public DNS publishes DoT behaviour and privacy profiles and explicitly discusses EDNS Client Subnet history and privacy profiles [2]. NextDNS and Mullvad offer DoH/DoT endpoints and position themselves as privacy-focused resolvers [3] [6]. These services encrypt stub-to-resolver traffic, but the resolver still learns the client IP by virtue of being the endpoint for that TCP/TLS/HTTPS connection [4] [7].
2. What “client IP privacy for third‑party resolvers” actually means
The question is not simply whether DoH/DoT encrypts DNS—those protocols do—but whether the resolver can associate query contents with the originating client IP. Standard DoH/DoT gives the resolver both the query and the client IP. Achieving client‑IP privacy relative to a third‑party resolver requires decoupling the client IP from query content via relay/proxy techniques or design changes to resolver architecture rather than switching from UDP to TLS/HTTPS alone [4] [8].
3. Providers or techniques that enable client IP protection
Current reporting and guides point to two practical approaches: use an anonymizing relay/proxy (Tor, SOCKS, anonymized DNS relays, or Anonymized DNSCrypt) or adopt multi‑party privacy mechanisms such as the IETF’s partitioning proposals (RFC 9230 referenced for decoupling ideas). PrivacyTools documents using Tor/SOCKS or anonymized DNS relays and Anonymized DNSCrypt as ways to achieve client IP protection when resolving via third‑party services [9]. DNSPrivacy materials and RFC discussions note experimental servers and work on designs that try to ensure no single DoH server sees both client IP and full query content [7] [8].
4. Where vendors stand: practical realities and caveats
Public resolvers advertise privacy-minded logging and short retention windows, yet they still receive client IPs when clients connect directly (Cloudflare, Google, NextDNS statements and analyses) [1] [2] [3]. Google’s documentation explicitly explains strict vs. opportunistic DoT profiles and how the server IP is obtained, underlining that direct connections reveal the client’s network address to the resolver [2]. Independent guides and comparisons repeatedly caution that encrypted transport does not equal anonymity and that organizations should read resolver privacy policies before relying on “encrypted DNS” as a means to hide their origin [4] [7].
5. Practical recommendation distilled from reporting
If the goal is to prevent a third‑party resolver from knowing the client IP, using a resolver’s DoH/DoT endpoint alone is insufficient; instead, employ an anonymizing relay (Tor/SOCKS), Anonymized DNSCrypt, or privacy‑partitioning designs under active IETF discussion—techniques explicitly recommended by PrivacyTools and dnsprivacy.org—or run a trusted recursive resolver under one’s control [9] [7] [10]. Major public providers (Cloudflare, Google, NextDNS, Mullvad) support DoH/DoT for encrypted queries, but none are shown in the cited reporting to provide default client‑IP anonymization for third‑party requests without those extra layers [1] [2] [3] [6].