Encrypted DNS Is a Double-Edged Sword: DoH, DoT and the Enterprise Visibility Gap

For most of the internet's history, DNS travelled in plaintext over port 53 — readable, filterable and loggable by anyone on the path. Encrypted DNS changed that. DNS-over-HTTPS (DoH) wraps queries inside ordinary HTTPS traffic on port 443; DNS-over-TLS (DoT) encrypts them on a dedicated port. For an individual on café Wi-Fi, this is a clear win: no snooping ISP, no coffee-shop attacker rewriting answers.

For an enterprise, the same technology has a second edge. When a browser or application ships with DoH enabled by default and pointed at a public resolver, its DNS queries silently leave the organization's control. The corporate resolver — with its threat feeds, category policy, logging and compliance evidence — simply never sees them. Security teams discover the gap the hard way: an incident review where the DNS logs for the affected machine are empty.

How the Visibility Gap Forms

The gap rarely arrives as one decision. It accumulates: a browser update turns on DoH silently, a developer's tool hardcodes a public resolver, an IoT device ships with its own encrypted DNS client, and malware authors — who adopted DoH early — hide C2 lookups inside TLS to public resolver IPs that no one dares block.

Because DoH rides on port 443, traditional firewall rules cannot distinguish it from ordinary web browsing. And with Encrypted Client Hello (ECH) increasingly hiding the destination hostname inside TLS handshakes, the network team's other fallback — SNI inspection — is fading at the same time.

• Browsers and OSes enabling DoH by default, bypassing corporate resolvers
• Applications and IoT devices with hardcoded public DoH endpoints
• Malware using DoH for command-and-control lookups invisible to port-53 monitoring
• ECH removing SNI as a fallback visibility signal
• Empty DNS logs during incident response — the gap discovered too late

Why 'Just Block It' Is the Wrong Answer

The reflexive response — block every known public DoH endpoint — ages badly. The list of public resolvers grows constantly, blocking them can break legitimate applications, and heavy-handed decryption of all TLS raises cost, latency and privacy objections of its own. Worse, it frames encryption as the enemy, when the real problem is *unmanaged* encryption: queries leaving through resolvers the organization does not operate and cannot see.

The sustainable posture is the one browser vendors themselves designed for: give devices an enterprise resolver that speaks encrypted DNS natively, and steer managed endpoints to use it. Chrome, Edge and Firefox honour enterprise policy and canary-domain signals precisely so organizations can keep protective resolution without stripping encryption from users.

Privacy AND Protection: The Managed Encrypted DNS Model

DNS Armor closes the gap by being the encrypted resolver your devices want to use. Endpoints, roaming laptops and branch sites resolve through DNS Armor over encrypted transports, so queries are private on the wire yet fully subject to threat intelligence, AI-based analysis, category policy and in-region logging. Enterprise policy then disables third-party DoH on managed browsers and devices, while resolver analytics expose the unmanaged encrypted DNS that remains — the fastest available signal for shadow devices and misbehaving software.

The result inverts the dilemma: users get stronger transport privacy than a public resolver offers (queries stay in your sovereign region rather than crossing to a global cloud), and the security team gets its visibility back — every query filtered, every log retained where regulators expect it.

• Encrypted resolution (DoH/DoT) to DNS Armor — privacy on the wire, policy at the resolver
• Enterprise browser policy and canary-domain signals steering managed endpoints
• Analytics that surface unmanaged third-party encrypted DNS still on the network
• AI threat detection and category filtering applied to every encrypted query
• In-region logging that keeps encrypted traffic compliant with residency rules