DNS over HTTPS and DNS over TLS: Privacy Gains, Visibility Loss

Traditional DNS is plaintext UDP on port 53. Every lookup a device makes is readable by anyone on the path and modifiable by anyone in a position to inject a response. Encrypted DNS fixes that, and in doing so creates a problem for the organizations that were relying on reading those queries.

The two mechanisms

DNS over TLS wraps ordinary DNS in a TLS session on TCP port 853. It is straightforward, and because it has a dedicated port, a network operator can see that encrypted DNS is happening and can permit or block it deliberately.

DNS over HTTPS carries queries inside HTTPS requests on TCP port 443, mixed in with all other web traffic. That is the design goal: DoH is intentionally difficult to distinguish from browsing, so it cannot be selectively blocked without blocking the web.

Both protect the same things — the query and the response are confidential in transit and cannot be tampered with. Neither hides the destination from the network entirely, since the subsequent connection still reveals an IP address, and TLS Server Name Indication often reveals the hostname anyway unless encrypted client hello is in use.

Note what neither provides: authentication of the DNS data. That is DNSSEC's job, and it is orthogonal. DNSSEC proves a record is genuine but sends it in the clear; DoH and DoT hide the query but do not prove the answer is authentic. Using both is the complete position.

Why the privacy case is real

Plaintext DNS discloses every site a user visits to the local network, the internet service provider, and anyone able to observe the path. It is also trivially manipulated: an on-path attacker can forge a response and redirect a client anywhere, and captive portals and some providers have historically rewritten responses as a matter of business practice.

For a user on public Wi-Fi or under a hostile network operator, encrypted DNS is a genuine improvement, and that is why browsers began enabling it by default.

What enterprises lose

DNS monitoring is one of the highest-value, lowest-cost detection sources a network has. Queries for known malicious domains, newly registered domains, algorithmically generated names produced by malware, and the long strange subdomains characteristic of DNS tunneling all show up in query logs. Many organizations catch command and control at the lookup, before any connection is established.

Internal DNS filtering also enforces policy. Blocking categories at the resolver is the cheapest content control there is, and it works for every device and protocol at once.

When a browser or application enables DoH to an external provider, all of it bypasses the internal resolver. The queries do not appear in logs, the filtering does not apply, and split-horizon name resolution breaks — internal hostnames stop resolving because the external provider has never heard of them. Understanding which DNS record types carry what makes it clearer how much detection signal is in that stream.

Restoring control

The workable answer is to run encrypted DNS yourself rather than fight it. Deploy an internal resolver that accepts DoH or DoT from your own clients, so queries are encrypted on the wire and still logged and filtered centrally. You get the privacy benefit against outsiders and keep the visibility.

Then stop clients from going elsewhere. Browsers can be configured by policy to use the system resolver or a specified endpoint, and enterprise policy templates exist for exactly this. Publish the canary domain that browsers query to detect a filtering network, which signals them to leave DoH off automatically.

Block outbound port 53 to anything but your resolvers, block 853 outbound to stop DoT, and block or redirect known public DoH endpoint addresses — imperfect, since the list changes, but it catches default configurations. Where traffic already passes through a secure web gateway with TLS inspection, DoH requests become visible as ordinary HTTPS to a resolver endpoint and can be handled by policy.

Whatever route you take, keep the resolver logs flowing into your SIEM. The detection value was never in the plaintext; it was in the log.

Exam angles

Know that DoT uses TCP 853 and DoH uses TCP 443, and that DoH's use of the web port is deliberate so it blends with other traffic. Recognize that both provide confidentiality and integrity in transit while DNSSEC provides authenticity of records, and that they solve different problems. Expect the enterprise scenario: encrypted DNS bypassing internal resolvers defeats filtering and monitoring, and the answer is an internal encrypted resolver plus policy enforcement, not simply blocking the protocol.