DNS over HTTPS (DoH)
DNS over HTTPS, specified in RFC 8484, carries DNS queries inside ordinary HTTPS requests so that resolution is encrypted and indistinguishable from web traffic. It provides confidentiality for the query and says nothing about whether the answer is genuine, which is a different problem with a different solution.
Encryption and authentication are not the same guarantee, and treating one as the other is the recurring error here. This protocol hides the query from anyone on the path. DNSSEC signs the answer so a resolver can prove it was not tampered with, and it does so in the clear. They are complementary, and neither substitutes for the other. Two related transports do the same job over different carriers, DNS over TLS on its own port and DNS over QUIC, and the difference matters operationally: a dedicated port can be blocked, and traffic mixed into port 443 cannot.
That last point is the security consequence for a defender. A large part of enterprise egress filtering, threat intelligence blocking and telemetry is built on seeing DNS. A browser or application that resolves names through an external provider over HTTPS removes all of it silently, and the switch is often a default rather than a decision by the user.
The workable position is not to fight the protocol but to own it: run the organisation’s own encrypted resolver, point clients at it by policy, and block or detect resolution that goes elsewhere. From an offensive perspective the same property is useful in the other direction, because a channel that looks like web traffic is a convenient place to hide a callback, which is precisely why the egress policy needs to name the resolver rather than the protocol.