An attacker sitting on a network link doesn’t need to crack your DNS over HTTPS to learn what you’re doing. The encryption hides the question. It doesn’t hide that you asked it, or who you asked. That gap is enough to fingerprint a flow, follow a user across a session, and build a map of every service your organization touches. The packets are encrypted. The metadata is wide open.

That uncomfortable truth surfaced again this week in the security press, and it cuts against a comfortable assumption a lot of teams have been operating on. Encrypted DNS got sold to the industry as a privacy win, and for the contents of a query, it is one. But cybersecurity has never been about one control doing one job. It’s about what an adversary can still see after that control does its job. With encrypted DNS, the answer is: more than you’d like.

Encryption Hides The Message, Not The Destination

DNS over TLS, DNS over HTTPS, and DNS over QUIC all do the same core thing. They wrap the query payload so the resolver conversation can’t be read in plaintext by anyone watching the wire. Good. The problem is everything that sits outside that payload.

The encryption covers the message inside each packet. The packet still carries plaintext headers, and those values mark a flow as DNS.

Port numbers, destination resolver IPs, packet sizes, and timing all leak. An observer who can’t read your query can still tell you’re doing DNS, see which resolver you’re using, and correlate the rhythm of your lookups with the connections that follow milliseconds later. If you resolve a hostname and then immediately open a TLS session to the IP that hostname points to, the SNI field or the destination address often gives the game away anyway.

This matters for two very different threat models, and most teams only think about one of them. The first is the eavesdropper, the network-position attacker you encrypted DNS to defeat in the first place. They get less than before, but they’re far from blind. The second threat model is the one nobody put on the slide deck: your own blind spot.

What Encrypted DNS Does To Your Cybersecurity Visibility

For years, DNS logs were one of the cheapest and richest threat detection sources you had. Malware beacons to a command-and-control domain, and the query lands in your resolver logs. A user gets phished and their browser resolves a lookalike domain, and there it is. Data exfiltration over DNS tunneling, newly registered domains, algorithmically generated C2 hostnames; all of it showed up as plain text you could pipe into detection logic.

Then endpoints started doing encrypted DNS on their own. A browser ships with DoH enabled and points at a public resolver. A managed laptop leaves the office network and stops asking your internal resolver anything. Suddenly the queries you used to inspect are wrapped in TLS and headed to an external provider you don’t run and can’t log.

The result is a quiet erosion of one of your best behavioral signals. Your firewall sees an encrypted session to a resolver. It does not see that the session contained a lookup for a domain registered four hours ago in a bulletproof hosting range. The encryption that protects your users from an outside watcher also protects an attacker’s beacon from you.

That’s the real tension. Defense in depth assumes you can see enough to act. When a control removes your visibility as a side effect, it isn’t free. You traded an external risk for an internal one, and if you didn’t notice the trade, you’re now worse off for threat detection while feeling more secure.

Close The Gap Before An Attacker Lives In It

You don’t fix this by ripping out encrypted DNS. You fix it by deciding, deliberately, where DNS resolution happens and making sure you keep eyes on it. The goal is simple: your organization’s lookups should flow through a resolver you control, where you can log, filter, and detect, and unauthorized encrypted DNS to the outside world should be blocked, not ignored.

• Run your own encrypting resolver. Stand up an internal DoH or DoT resolver and point endpoints at it. You get the privacy benefit on the wire and you keep the query log on a box you own.
• Block rogue DoH. Disable browser-level DoH through enterprise policy and block known public DoH resolver endpoints at the firewall. An endpoint quietly resolving through a public provider is an endpoint you can’t monitor.
• Log queries off-host. Ship resolver logs to a central store an attacker can’t reach from a compromised endpoint. Query logs are only useful for incident response if they survive the incident.
• Hunt the metadata you do have. Even where payloads are encrypted, flow records, destination IPs, and timing tell a story. Baseline normal resolver traffic so an endpoint suddenly beaconing to an unfamiliar resolver stands out.
• Watch for the unexpected. Alert on direct port 53 traffic leaving the network, on connections to public DoH endpoints, and on devices that stop talking to your internal resolver entirely.

Treat this as security hardening with a feedback loop, not a one-time config change. Re-check it after every OS update and browser rollout, because vendors flip DoH defaults without asking you. The control you set in March can be silently undone by an update in June.

None of this is exotic. It’s the same discipline that separates teams who survive a brute-force campaign or a fast-moving edge exploit from teams who find out three weeks later in a ransom note. Know where your data flows. Keep visibility on the flows you care about. Assume any control that promises privacy or threat-protection is also reshaping what you can see, and account for the part it took away.

Encrypted DNS is a good thing to deploy. Just deploy it with your eyes open, on infrastructure you run, with logging you control. The alternative is handing both the eavesdropper and your own attacker the one thing they want most: a network where the interesting traffic is invisible to everyone except them.

Sources

• Week in review: Fortibleed campaign’s impact on orgs, Cisco Unified CM flaw exploited