DNS over HTTPS encrypts your name lookups so your ISP and local network cannot read or modify them. Turn it on for most personal use, but leave it off where you rely on a local resolver for internal hostnames, network-level content filtering, or security monitoring.
What DoH is, and what DoT and DoQ are
Classic DNS, unchanged in its essentials since 1987, sends queries as plaintext UDP on port 53. Anyone on the path, including your ISP, the operator of any Wi-Fi network you join, and anyone able to observe the link, can read every domain you look up and can also forge a reply, since there is no authentication of the answer.
DNS over HTTPS, specified in RFC 8484, wraps those queries in an ordinary HTTPS request to a resolver endpoint, typically a URL ending in /dns-query, carried on port 443 alongside all other web traffic. Observers see an encrypted connection to a resolver operator and nothing about its contents. Because it uses port 443, DoH traffic is difficult to block selectively without blocking the resolver's address entirely.
DNS over TLS, specified in RFC 7858, achieves the same confidentiality but uses a dedicated port, 853. This makes it cleanly identifiable, which network administrators prefer because it can be permitted or denied as a policy decision, and which privacy advocates dislike for the same reason. Android's Private DNS feature uses DoT.
DNS over QUIC, specified in RFC 9250, uses port 853 over QUIC for lower latency on lossy connections. Support is growing but remains less common than DoH and DoT.
All three protect the query in transit only. None of them provides any assurance about what the resolver does with the query once it arrives.
DoH and DNSSEC solve different problems. DNSSEC cryptographically signs DNS records so a resolver can verify that an answer is authentic, but it does not encrypt anything. DoH encrypts the conversation but does not validate the data. They complement each other; neither substitutes for the other.
What it protects and what it does not
It is worth being precise here, because DoH is frequently oversold.
What it protects: the content of your DNS queries from your ISP, from other users on a shared network, and from a hostile Wi-Fi operator. It also prevents DNS-based redirection, where a network intercepts port 53 traffic and returns its own answers, a technique used for captive portals, ISP search-hijacking pages, and censorship.
What it does not protect: the destination of your traffic. After the lookup resolves, your device opens a connection to the resulting IP address, and that address is fully visible to your ISP. For a site on dedicated infrastructure, the address alone identifies it. For a site behind a large CDN, the address is shared with thousands of others, which does provide meaningful ambiguity.
It also does not hide the server name in the TLS handshake. Unless Encrypted Client Hello is in use, the SNI field carries the hostname in plaintext at connection time, which reveals exactly what DoH just encrypted. This is the single largest gap in the protection DoH is usually described as providing, and closing it requires ECH, which in turn requires DoH to fetch the ECH key. The two work together or not at all.
And it does not hide anything from your chosen resolver. You have moved visibility from your ISP to Cloudflare, Google, Quad9 or whoever you selected. That is a meaningful improvement if you trust that operator more than your ISP, which for most US consumers is a reasonable position given that ISPs have been permitted to monetise browsing data since 2017. It is not anonymity.
Choosing a resolver
The choice matters more than the protocol, because the resolver sees everything. Evaluate on retention policy, filtering behaviour, jurisdiction and performance, in that order.
The major public options and their DoH endpoints are below. All of them also offer DoT on port 853 at the equivalent hostname.
- Cloudflare:
https://cloudflare-dns.com/dns-query, IPv4 1.1.1.1 and 1.0.0.1, IPv6 2606:4700:4700::1111. Filtering variants at 1.1.1.2 (malware) and 1.1.1.3 (malware and adult content). AS13335. - Google Public DNS:
https://dns.google/dns-query, 8.8.8.8 and 8.8.4.4, IPv6 2001:4860:4860::8888. No filtering. AS15169. - Quad9:
https://dns.quad9.net/dns-query, 9.9.9.9 and 149.112.112.112. Blocks known malicious domains by default; 9.9.9.10 is the unfiltered variant. Operated by a Swiss non-profit foundation. - AdGuard DNS:
https://dns.adguard-dns.com/dns-query, 94.140.14.14 and 94.140.15.15. Blocks advertising and tracking domains; a family variant blocks adult content. - NextDNS:
https://dns.nextdns.io/<your-config-id>. Per-account configurable filtering, logging you control including the option to disable it entirely, and detailed query analytics. - Mullvad DNS:
https://dns.mullvad.net/dns-query, free and unlogged, with ad-blocking variants at different hostnames. - Control D:
https://freedns.controld.com/<profile>, configurable filtering profiles.
Latency differences between major resolvers are usually a few milliseconds and are dominated by cache hit rates rather than raw distance. Measure rather than assume: for s in 1.1.1.1 8.8.8.8 9.9.9.9; do echo -n "$s "; dig +stats @$s example.com | grep "Query time"; done
Turning it on: system and browser
System-level configuration is preferable, because it covers every application rather than one browser. Browser-level DoH leaves your email client, your operating system's update checks and every other program using the network resolver.
On Windows 11: Settings, Network and internet, Wi-Fi (or Ethernet), Hardware properties, then Edit next to DNS server assignment. Set the dropdown to Manual, switch IPv4 to On, enter your resolver addresses, and set Preferred DNS encryption to Encrypted only (DNS over HTTPS). Windows recognises the major providers automatically; for others, register the template first with Add-DnsClientDohServerAddress.
On macOS: install a DNS settings configuration profile containing a DNSSettings payload with DNSProtocol set to HTTPS and the ServerURL for your resolver. Most public resolvers publish a ready-made profile. Installed profiles appear under System Settings, General, Device Management, and apply system-wide.
On Android: Settings, Network and internet, Private DNS, then Private DNS provider hostname, entering for example dns.quad9.net or one.one.one.one. This uses DoT rather than DoH and applies to all applications.
On iOS: install a DNS configuration profile, or use an app that installs one. There is no built-in manual DoH field.
In browsers: Firefox at Settings, Privacy and Security, DNS over HTTPS, offering Default Protection, Increased Protection and Max Protection. Increased uses DoH and falls back to system DNS on failure; Max uses DoH and fails rather than falling back. Chrome and Edge at chrome://settings/security and edge://settings/privacy, under Use secure DNS.
# Windows: register a custom DoH template, then use it
Add-DnsClientDohServerAddress -ServerAddress 9.9.9.9 -DohTemplate https://dns.quad9.net/dns-query -AllowFallbackToUdp $false -AutoUpgrade $true
Get-DnsClientDohServerAddress
# check what Windows will use
Get-DnsClientServerAddress -AddressFamily IPv4
# test a DoH endpoint directly
curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
dig +https @1.1.1.1 example.com # dig 9.17 and laterWhen to leave it off
There are legitimate cases where DoH is the wrong choice, and they are not edge cases.
Corporate and managed networks. If your employer runs internal DNS zones, a browser using an external resolver cannot resolve internal hostnames, and split-horizon DNS breaks. Chrome and Firefox both attempt to detect managed networks and disable DoH automatically, but the detection is imperfect. If your VPN or intranet stops working after enabling DoH, this is why.
Network-level filtering you rely on. Pi-hole, AdGuard Home, a router-based blocklist, or parental controls implemented at the DNS layer are all bypassed by a browser talking directly to an external resolver. Enabling browser DoH silently disables your own ad blocking. If you run a local filtering resolver, either leave browser DoH off, or configure DoH pointing at your own resolver, which most local filtering software now supports.
Security monitoring. Enterprise environments frequently inspect DNS for indicators of compromise; encrypted queries to an external resolver bypass that visibility. This is a genuine security trade-off, not merely an organisational preference.
The resolution in most of these cases is to point DoH at the right resolver rather than to abandon encryption. A local Pi-hole or AdGuard Home instance can serve DoH to your own network while forwarding upstream over DoH itself, giving you filtering, internal name resolution and encryption at once.
Enabling DoH in a browser while running a Pi-hole is the most common self-inflicted failure in this area. Advertising reappears, the query log goes empty, and the cause is not obvious. Check Firefox's Settings, Privacy and Security, DNS over HTTPS, and Chrome's Use secure DNS toggle before troubleshooting the resolver.
Verifying it is actually working
Configuring DoH and having DoH in use are different things, and several conditions cause a silent fallback to plaintext port 53: a network blocking the resolver, a canary domain signalling a managed network, or a browser's automatic detection deciding to disable it.
The definitive check is at the packet level. Watch for outbound traffic on port 53 while browsing. On a correctly configured system with system-wide DoH, there should be essentially none beyond local multicast DNS on port 5353.
Firefox reports its own status at about:networking#dns, where each entry shows whether it resolved over TRR, the Mozilla term for DoH. Chrome exposes no equivalent view, so packet capture is the reliable method there.
Also confirm which resolver is answering, not merely that encryption is in use. A network that intercepts and re-encrypts, or a browser silently using a different provider than you configured, both produce encrypted traffic to the wrong place.
# should show essentially nothing while browsing
sudo tcpdump -n -i any 'udp port 53 or tcp port 53'
# should show traffic to your resolver's address on 443
sudo tcpdump -n -i any 'host 1.1.1.1 and tcp port 443'
# which resolver answered
dig +short whoami.akamai.net
dig +short chaos TXT id.server @1.1.1.1
# Firefox: open about:networking#dns and check the TRR column
# Windows: confirm the DoH template is applied
Get-DnsClientDohServerAddressFrequently asked
Does DNS over HTTPS hide my browsing from my ISP?
It hides which domains you look up, but not which addresses you connect to afterwards, and not the server name in the TLS handshake unless Encrypted Client Hello is also in use. Your ISP can still infer most destinations from IP addresses and SNI. DoH is a meaningful improvement, not concealment.
Is DoH or DoT better?
For confidentiality they are equivalent. DoH on port 443 is harder for a network to block selectively, which favours users on restrictive networks. DoT on port 853 is cleanly identifiable, which network administrators prefer for policy enforcement. Android uses DoT natively; browsers and Windows use DoH.
Does DoH break my Pi-hole?
Browser-level DoH does, because the browser bypasses your local resolver entirely and your filtering stops applying. The fix is to either disable DoH in the browser, or configure the browser and system to use your Pi-hole as the DoH endpoint, which recent Pi-hole and AdGuard Home versions support.
Which DoH provider should I use?
Pick on retention policy and filtering behaviour rather than speed, since latency differences are typically a few milliseconds. Quad9 blocks known malicious domains and is run by a Swiss non-profit. Cloudflare publishes short retention commitments. NextDNS gives per-account control including disabling logging. All are reasonable choices.
Will DoH slow down my browsing?
Marginally at most, and it can be faster. DoH adds TLS handshake overhead on the first query, but connections are reused for subsequent lookups, and a well-provisioned public resolver often has better cache hit rates than an ISP resolver. Measure with dig +stats against several resolvers rather than assuming.