DNS over HTTPS vs DNS over TLS

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS exchanges between a client and its chosen resolver. Both protect this part of the path against casual inspection and modification on the network. Neither makes website visits wholly invisible or anonymous.

How requests travel

DoH maps DNS queries and responses onto HTTPS exchanges; RFC 8484 defines the protocol. DoT carries DNS messages inside a dedicated TLS connection, specified by RFC 7858. Both require client and resolver support as well as authentication of the resolver. A setting called “secure DNS” alone does not tell you which provider is selected or whether the device can fall back to ordinary DNS.

DoH is often built into a browser or application and may use ordinary HTTPS infrastructure. DoT is commonly configured by the operating system or network and uses a distinct DNS connection. These are common patterns, not guarantees: actual behaviour depends on the device, application and network policy. Neither a port number nor a protocol label proves a service is trustworthy.

What remains visible

The chosen resolver operator receives the queries needed to answer. The destination website sees a connection, while other network participants may see connection IP addresses and other metadata. Encrypted DNS does not erase browser history, cookies, account sign-ins or information you submit to a site. For privacy decisions, examine the full connection path and the resolver’s data policy.

DNSSEC serves a different purpose. It can validate the origin and integrity of signed DNS data when the chain of trust is configured; it does not encrypt client-to-resolver queries. A DoH or DoT resolver can also validate DNSSEC. Treat these mechanisms as complementary rather than interchangeable.

Check the actual configuration

Find out whether the browser uses the system DNS configuration or its own encrypted resolver. Compare the expected answer with the DNS configuration checker and a query through the selected resolver. Differences do not always mean a leak: a CDN may tailor answers to resolver location and other conditions. Also test what happens when the encrypted resolver is unavailable.

On a managed network, filtering, internal names and security policy may require a particular resolver. An arbitrary DNS change can break internal resources. Before adjusting settings, identify who operates the network, which names must resolve and whether an alternative DNS path is allowed.

Choose deliberately

Assess a provider’s availability, data handling, DNSSEC validation and failure behaviour rather than a single privacy promise. Test ordinary websites and necessary internal names after making a change. If the underlying problem is an incorrect authoritative record, changing DNS transport cannot correct it.