Regular DNS queries travel over UDP in plaintext — your ISP, a corporate network or an attacker can see which sites you visit. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) solve this problem by encrypting DNS traffic.

Comparison: plain DNS vs DoH vs DoT

Parameter	DNS	DoH	DoT
Port	53/UDP	443/TCP	853/TCP
Encryption	None	HTTPS/TLS	TLS
Privacy	Low	High	High
Bypassing blocks	No	Yes (port 443)	Partially
Browser support	Always	Chrome, Firefox	System-wide only

Public DoH servers

Provider	URL	Logging policy
Cloudflare	https://1.1.1.1/dns-query	No logs
Google	https://dns.google/dns-query	48-hour logs
Quad9	https://dns.quad9.net/dns-query	No logs, blocks malware
NextDNS	Individual URL	Configurable logging

Enabling DoH in Firefox

Settings → Privacy & Security
Scroll down to "DNS over HTTPS"
Turn it on → pick a provider (Cloudflare/NextDNS)

Enabling DoH in Chrome

Settings → Privacy and security
Security → Use secure DNS
Pick a provider or enter your own DoH URL

Configuring DoH on Linux (systemd-resolved)

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1
FallbackDNS=8.8.8.8
DNSOverTLS=yes

systemctl restart systemd-resolved

💡 For stronger privacy: Use Cloudflare 1.1.1.1 (it commits to not selling data) or Quad9 (blocks malicious domains automatically). Avoid providers that monetize DNS queries.

Common DoH Setup Errors

Symptom	Cause	Fix
Firefox shows "Secure DNS unavailable"	The DoH provider is blocked by the network firewall or a corporate proxy on port 443 via SNI filtering	Switch to a different DoH provider in settings or temporarily disable DoH on this network
Chrome shows the warning "Could not find a secure DNS provider"	Chrome checks whether the current system DNS supports DoH through auto-upgrade and finds no match	Pick a DoH provider manually instead of the "With current service provider" mode
systemd-resolved: DNSOverTLS=yes, but `resolvectl status` shows "not supported"	The resolver listed in DNS= doesn't support TLS on port 853, or its certificate doesn't match the name in the DNSOverTLS configuration	Specify an explicit certificate name with `#` before the IP, or switch to a resolver confirmed to support DoT (1.1.1.1, 8.8.8.8)
Internal (intranet) sites stop opening after enabling DoH	Internal DNS records only exist on the corporate resolver, while DoH queries a public server that doesn't know about them	Add the intranet domains to the DoH exclusion list (Firefox: `network.trr.excluded-domains`) or disable DoH on this network
ISP-level parental controls/DNS filtering stop working	DoH bypasses the ISP's DNS servers, so DNS-based filters (including antivirus and parental filters) no longer see the queries	Use a DoH provider with built-in filtering (for example CleanBrowsing or AdGuard DNS) instead of disabling filtering entirely

Verifying That DoH Actually Works

# Firefox: diagnostics page
about:networking#dns

# Check directly against the DoH endpoint with curl
curl -s -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=example.com&type=A'

# Check for DNS leaks outside DoH (the list of regular resolvers should be empty)
# https://www.dnsleaktest.com

If the curl request returned JSON with "Status": 0 and an Answer array, the DoH endpoint is responding correctly. A "Status": 2 code means SERVFAIL on the DoH resolver's side, not a problem in your setup.

In Firefox: about:networking#dns — the TRR (Trusted Recursive Resolver) column should be marked for domains going through DoH
In Chrome: chrome://net-internals/#dns — the "DNS over HTTPS" section shows stats for successful queries
A DNS leak test should not show your ISP's resolver — only the DoH/DoT server you selected

When DoH Is Not a Good Fit

A corporate network with its own DNS zone for internal services — the DoH provider can't resolve intranet names, so sites and VPN-only services stop opening without explicit exclusions
You need network-level DNS-based filtering (parental controls, antivirus, ad blocking via pfBlockerNG/Pi-hole) — DoH in the browser bypasses these filters unless you explicitly set the same filtering DNS as the DoH provider
Network troubleshooting — tcpdump and regular DNS sniffers can't see the contents of DoH queries; they're encrypted like ordinary HTTPS traffic
Older routers and IoT devices almost never support DoH/DoT — it makes more sense to enable it at the OS or browser level than to rely on it as your only network defense