The DNS Encryption War: Threat Visibility When the Resolver Goes Dark

DNS has always been the most cost-effective place to stop an attack. A malicious domain lookup happens before the malware connects to command and control, before the phishing page renders, and before the credential leaves the endpoint. Blocking at the resolver costs a fraction of what blocking at the endpoint costs, and it works for devices you cannot install software on. The trouble is that the entire premise depends on being able to see the question being asked — and in 2026, that assumption is under sustained pressure.

What Changed

Encrypted transports for DNS are now the default rather than the exception. DNS over HTTPS, DNS over TLS, DNS over QUIC, and HTTP/3 variants all remove the plaintext query from the wire, and mainstream browsers ship with a public resolver preference enabled unless an administrator intervenes. Encrypted Client Hello compounds the effect: where SNI once revealed the hostname in plaintext even when the query itself was hidden, ECH encrypts that field too, and it has been on by default in Firefox since version 119. From a network perspective, the visible trail is thinning out fast.

The Security Trade-Off Is Real, and It Cuts Both Ways

Academics studying DoH adoption noted early that it makes it materially harder for administrators to inspect and filter DNS traffic — the same property that protects a user on hostile Wi-Fi also defeats the enterprise's protective DNS. Attackers have noticed. Encrypted DNS and DNS tunneling are now routinely used to move command-and-control traffic past inspection, and reported DNS-related incidents remain nearly universal across enterprise surveys. Meanwhile, from the user's perspective, the encryption is genuinely protective: it defeats ISP-level snooping and basic DNS hijacking, though it does nothing about a compromised resolver.

Stop Fighting Encryption, Move the Control Point

• Run your own encrypted resolver: Give users the privacy of encryption with a filtering resolver you operate. It is the only way to keep both properties at once.
• Pin resolver policy by management: Configure browser DoH policies centrally and disable automatic fallback to public resolvers you do not control. The goal is not to outlaw encrypted DNS; it is to ensure the encryption terminates somewhere you govern.
• Prefer DoT awareness over DoH blocking: DoT is comparatively easy to identify and manage because it uses a dedicated port, while DoH blends into ordinary web traffic. Pick the transport you can actually reason about.
• Rebuild visibility at the endpoint: With SNI hidden and queries encrypted, the network sensor is a diminishing asset. Endpoint network telemetry and DNS logging on the device become primary rather than secondary.
• Log and alert on resolution behavior: Anomalous lookups, new resolver usage, and long-lived tunnels are detectable at the resolver even when payloads are opaque.

Treating encrypted DNS as an adversary to be blocked is a losing position: you will degrade user privacy, break ordinary applications, and still miss the traffic that tunnels through. The durable strategy is to own the resolver, pin the policy, and relocate the visibility that encryption removed. Threat detection did not get worse in 2026 — it moved, and the controls that stayed in the network path are the ones now in the dark.