DNS over HTTPS: What It Hides and What It Does Not

DNS was designed without any protection. Queries and answers travel in the clear, so anyone on the path can read which names a device is looking up and, with a little more effort, alter the answers. DNS over HTTPS addresses the reading and the altering. It is frequently described as making browsing private, which overstates considerably what it does.

What It Changes

An ordinary DNS query leaves the device in plain text on a well-known port. Every device between the client and the resolver can read it, log it, and modify the response.

DoH wraps the same query in an HTTPS request to a resolver that speaks the protocol. The exchange is encrypted and authenticated in the same way as a web request, so an observer on the path sees an HTTPS connection to that resolver and nothing about the names inside it.

Two things follow. Reading the query requires being the resolver rather than being on the path. And modifying the answer, which is how many filtering and redirection systems work, is no longer possible from the middle.

What It Does Not Change

The connection that follows the lookup is not hidden. Once the name resolves, the device opens a connection to the resulting address, and that address is visible in every packet.

For a server hosting one site, the address identifies the site. For a large shared platform it identifies the platform rather than the specific site, which is a meaningful difference but not anonymity.

Connection setup also often carries the server name in a form an observer can read, depending on what both ends support. Where it does, the name is exposed at that point regardless of how the lookup was done.

Why It Breaks Networks

Internal names exist only on internal servers. A company’s file server, a printer, a management interface, all resolve through DNS that is aware of them.

A browser configured to use a public DoH resolver bypasses the DNS the network handed it. Queries for internal names go to a resolver that has never heard of them, and the answer is that they do not exist. The visible symptom is that public sites work and internal resources do not, which sends people looking at the internal servers rather than at the browser.

The same applies to split-horizon arrangements, where a name resolves to an internal address inside the network and a public one outside. A device using an external resolver always gets the public answer, which may be unreachable from inside.

Filtering is affected the same way. Content filters that work by answering DNS queries have nothing to answer if the query never reaches them.

Choosing Where to Resolve

The question is not whether encryption is good. It is which resolver you want to trust and which network you are on.

On an untrusted network, encrypting DNS is a straightforward improvement. The alternative is every device on that network being able to read and alter your lookups.

On a managed network with its own DNS, sending queries elsewhere breaks name resolution and any policy attached to it. The right configuration there is either to disable DoH on the client or to point it at the local resolver if that resolver supports encrypted transport, which increasingly they do.

Many operating systems and browsers now enable DoH automatically under some conditions and fall back when the network appears to require its own DNS. The heuristics work reasonably and they are not universal, which is why this shows up as an unexplained resolution failure.

DoH Against DoT

DNS over TLS encrypts the same exchange on its own dedicated port. Because the port is distinct, the traffic is identifiable as DNS and a network can choose to permit, block or redirect it as a category.

DoH is deliberately indistinguishable from other HTTPS traffic. That is a feature where the concern is censorship and an obstacle where the concern is network management.

Neither is more or less encrypted than the other. The difference is entirely in whether the traffic can be recognised.

What People Get Wrong About This

The first mistake is believing it makes browsing private. It closes the DNS channel and leaves the destination address visible.

The second is enabling it on a work machine and then troubleshooting the internal DNS servers when internal names stop resolving.

A third is assuming the resolver is trustworthy because the connection is encrypted. Encryption protects the query from the path; it does not constrain what the resolver at the other end does with it. Choosing a DoH provider is choosing who gets to see every name you look up.

A fourth is expecting it to bypass filtering reliably. Filtering that works on IP addresses or on connection inspection is unaffected.

And the last is deploying it without considering that some devices on the network cannot be configured at all, so a mixed environment results in inconsistent resolution.

Diagnosing It

When name resolution behaves differently in one browser from the rest of the system, the browser’s own DNS setting is the first place to look. That asymmetry is close to diagnostic.

Otherwise the usual tools still apply: checking what the system resolver returns against what the application appears to be getting. How DNS resolution works covers the normal path, and the difference between that path and what an application is doing is the whole question here.