Secure DNS (DoH and DoT): Stopping Your ISP and Network From Seeing Every Site You Visit

Secure DNS encrypts the lookup that turns a hostname into an IP address, so your ISP, your Wi-Fi network and anyone on the path can no longer read or forge it. DNS over HTTPS and DNS over TLS both do this; they differ only in transport. They hide which sites you resolve from the network, not from the resolver you choose, and not the destination address itself.

Why the lookup is the weak point

Before a browser can connect to example.com it must ask a resolver for the address. That question and its answer have, since 1983, travelled as plain text UDP packets on port 53. The consequences are two. First, every network between you and the resolver sees the full list of hostnames you visit, which is a nearly complete record of your browsing even when every page itself is HTTPS. Second, anyone who can intercept the packet can answer it with an address of their choosing, sending you to a server they control. Hotel networks do this to show login pages; some ISPs have done it to insert advertising on typo domains; attackers do it for phishing.

DNSSEC addresses the second problem by signing answers so a forgery can be detected, and it is worth having on domains you run, which is why our website scanner reports DNSSEC signing. It does nothing about the first problem. The lookups are still visible. Encrypting the transport is what removes the observer, and that is what secure DNS means.

DoT, DoH and DoQ

Functionally DoT and DoH give the same result: the query is encrypted end to end between you and the resolver. The practical differences are about who can interfere. DoT's dedicated port makes it simple for a network to block, forcing a fallback; DoH hides among web traffic and is much harder to block selectively. That is exactly why enterprise networks prefer DoT or a managed resolver, and why browsers chose DoH. Mozilla even defined a canary domain, use-application-dns.net, which a network can make unresolvable to signal that Firefox should not enable DoH automatically.

What secure DNS hides, and what it does not

Be precise here, because this is where expectations go wrong.

• Hidden from the network: the hostnames you look up. Your ISP and the coffee shop no longer see mail.example in a DNS packet.
• Still visible to the network: the IP address you then connect to, which for a large site identifies the service and for a small one identifies it exactly. Also visible is the Server Name Indication field in the TLS handshake, which names the host in plain text, unless the connection uses Encrypted Client Hello.
• Visible to the resolver: everything. You have moved the observer from your ISP to Cloudflare, Google, Quad9, NextDNS or whoever you chose. This is a change of who to trust, not an elimination of trust. Choose a resolver with a published, audited privacy policy.
• Not protected: the content of your traffic, which is HTTPS's job, and your own address, which is a VPN's job. Which tools cover which observer is laid out in VPN vs proxy vs Tor.

Encrypted Client Hello closes the SNI gap. It encrypts the server name using a key published in the site's DNS HTTPS record (RFC 9460), and it only works when the DNS lookup that fetched that key was itself private, so ECH depends on secure DNS. Firefox and Chrome enable ECH when DoH is on and the site supports it; a growing share of sites behind large CDNs do. With DoH plus ECH, a network observer is left with destination IP addresses and traffic patterns, which is a substantial improvement over the plain-text hostname list they had before.

Turning it on

Firefox

Settings > Privacy & Security > DNS over HTTPS. Four levels: Off; Default Protection, which uses DoH where Firefox thinks it is safe and falls back to the system resolver on networks that object, such as those setting the canary domain or using parental controls; Increased Protection, which uses your chosen DoH provider and falls back only if it fails; and Max Protection, which never falls back and shows an error instead. Increased is the right choice for most people; Max if you want to know when a network is interfering. Firefox has enabled DoH by default for users in the United States since 2020 and in Canada since 2021.

Chrome and Edge

Chrome: chrome://settings/security > Use secure DNS. Edge: edge://settings/privacy > Use secure DNS. Both offer With your current service provider, which upgrades to DoH only if your existing resolver is on the browser's list of providers known to support it, and With a named provider or a custom template such as https://dns.quad9.net/dns-query. The first option silently does nothing on many ISP resolvers, so choose a provider explicitly if you want a guarantee.

Safari, macOS and iOS

Safari has no DNS setting; it uses the system resolver. Apple supports DoH and DoT system-wide since macOS 11 and iOS 14, configured either by installing a DNS configuration profile from a resolver operator or by an app that uses the encrypted-DNS API. Once installed, every app on the device, Safari included, uses the encrypted resolver. This is arguably the better design: a browser-only setting leaves email clients, updaters and every other program on plain DNS.

Operating systems and routers

Windows 11 supports DoH per network adapter under Settings > Network & internet > the adapter > DNS server assignment > Edit, choosing a manual server and setting DNS over HTTPS to On. Android offers Private DNS under Network & internet, which uses DoT with a hostname such as dns.quad9.net. Many home routers can forward all DNS over DoT or DoH so that every device on the network benefits without configuration.

A worked example

You can watch the difference. With plain DNS, a packet capture on your own machine shows the query in the clear:

$ dig example.com A +short
93.184.216.34
# on the wire: UDP 53, "example.com IN A" readable by anyone on the path

With DoH, the same lookup is an HTTPS request to the resolver and shows up on the wire as TLS to port 443:

$ curl -s -H 'accept: application/dns-json'   'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
{"Status":0,"Answer":[{"name":"example.com","type":1,"TTL":300,"data":"93.184.216.34"}]}
# on the wire: TLS to cloudflare-dns.com; the name "example.com" is not visible

The JSON form is a convenience for humans; browsers use the binary wire format on the same endpoint. After enabling secure DNS, confirm it with the WebRTC and IP leak test, which reports the resolver your browser actually used; a result still showing your ISP's resolver means a fallback occurred or the setting did not take. The same pattern of verifying rather than trusting a toggle applies to all of browser security settings.

Objections, and where they are right

Network administrators object that DoH bypasses their filtering, and they are correct; a browser that resolves through Cloudflare ignores a school's or company's blocklist. Browsers handle this by respecting the canary domain, by disabling automatic DoH under enterprise policy, and by falling back at the Default level. On a managed network this is reasonable, and on a personal device on a public network it is the whole point. Privacy advocates object that centralising lookups on a few large resolvers creates a different kind of observer, and they are also correct, which is why the resolver choice deserves more thought than the toggle. A resolver run by a nonprofit with a no-logging policy, or one you run yourself on a VPS with DoH enabled, are both credible answers.

What is not credible is leaving DNS in plain text in 2026 while worrying about HTTPS. The hostname list is the most revealing metadata a network observer gets, and encrypting it is a one-time setting. Secure DNS pairs naturally with HTTPS-only mode in the browser and, on the domains you operate yourself, with the email and DNS protections in SPF, DKIM and DMARC explained. The larger context of what your connection reveals is in what your IP address reveals and the browser security hub.