DNS-over-HTTPS for Corporate Networks: The 2026 Tradeoffs

# DNS-over-HTTPS for corporate networks: the 2026 tradeoffs

Every DNS filtering vendor sold the same story for 20 years. Block malicious domains at the DNS layer. Log every query for forensic visibility. Detect data exfiltration by catching the C2 beacon lookup. The whole enterprise security model for DNS-based detection assumed one thing. The browser does what the OS tells it to do.

That's not true anymore. Firefox ships DoH on by default. Chrome respects the user's device-level DNS if it supports DoH. Edge falls back to Microsoft's resolver. All three bypass the corporate resolver, encrypt the lookup, and leave your $200K DNS security stack staring at zero traffic.

This is the problem we get asked about on most network-security audits. Your DNS logs say the network is quiet. The network isn't quiet. You're blind.

This post covers the 2026 state of DoH in the enterprise, the three workable strategies (allow it, break it, replace it), and what each one costs you operationally.

The 2026 state of DoH in enterprise environments. It's not as simple as "block DoH" or "embrace DoH."

#The defender's problem

What we actually see in the field diverges from what the vendors describe. Here's the unvarnished version.

Traditional enterprise DNS security:

1. Endpoint makes DNS query
2. Corporate DNS server (or DHCP-assigned DNS) sees query
3. Query compared against threat intelligence (is this a known C2 domain? Malware? Phishing? DGA pattern?)
4. Query logged for later investigation
5. Response returned or blocked

This gives defenders:

• Blocking of known-malicious domains
• Detection of compromised endpoints (repeatedly querying C2 infrastructure)
• Data exfiltration detection (DNS tunneling over thousands of queries with encoded data)
• Evidence for incident response (who connected to what, when)

DoH routes around all of this. An application configured to use Cloudflare's 1.1.1.1 DoH endpoint, or Google's 8.8.8.8 DoH, or any of dozens of public resolvers sends its DNS queries encrypted over port 443 to a trusted public resolver. The corporate network sees an HTTPS connection to 1.1.1.1 and can't inspect the queries inside.

#What uses DoH today

• Firefox: DoH enabled by default to Cloudflare or the user's choice in some regions
• Chrome / Chromium: DoH available, user-selectable, default off but many users enable
• Microsoft Edge: DoH enabled by default in some configurations
• macOS: system-level DoH support since macOS 11, applications can opt in
• iOS: same
• Windows 11: system-level DoH supported
• Android 9+: "Private DNS" feature supports DoT/DoH
• Many apps: custom DoH configurations bypassing OS entirely. Ad blockers, privacy tools, even some malware

#Enterprise defense options

#Option 1: Block DoH entirely

Identify and block all known DoH endpoints at your egress firewall. Force all DNS queries to go through the corporate resolver.

How:

• Firewall rules blocking IP addresses of public DoH providers (Cloudflare, Google, Quad9, OpenDNS, NextDNS, etc.)
• Application-layer inspection of HTTPS traffic to detect DoH pattern (HTTP/2 over 443 with specific URL paths like /dns-query)
• SSL inspection on firewalls that can see the URL within HTTPS
• Configure Windows Group Policy to disable DoH in Edge / Chrome
• Configure MDM policy to disable DoH on managed endpoints
• Configure macOS configuration profiles to force system DNS

Pros: preserves traditional DNS visibility, works with existing DNS security stack.

Cons: cat-and-mouse game. DoH providers update IPs, new providers emerge. Users on BYOD or personal apps may still use DoH. Sophisticated malware will use DoH or DoT to evade.

#Option 2: Provide your own DoH resolver

Stand up an internal DoH resolver, push configuration to all endpoints forcing use of the internal DoH endpoint, block public DoH as above.

How:

• NextDNS, Cloudflare Gateway (as enterprise), or a self-hosted DoH resolver (CoreDNS, Unbound, Pi-hole with DoH plugin)
• MDM-push the DoH configuration to all endpoints
• Endpoint uses internal DoH, internal DoH applies your threat intelligence and filtering

Pros: modernizes the stack, preserves visibility, benefits from DoH encryption for the enterprise + user privacy on the internal link.

Cons: infrastructure complexity, licensing cost for enterprise DoH, endpoint management complexity.

What we see deployed most often in 2026 for enterprises that care about both DNS security and DoH adoption.

#Option 3: SSE / SWG-based DNS security

Let a cloud-delivered Security Service Edge (Cloudflare One, Zscaler, Netskope, Palo Alto Prisma) handle DNS filtering. Their clientless / agent-based architecture routes DNS through their infrastructure regardless of whether the endpoint is on corp network or at home.

Endpoints run an agent (WARP, Zscaler Client Connector, Netskope Client). The agent captures DNS queries, runs them through the SSE provider's threat intelligence, and returns results. Works whether the endpoint is on-network, remote, or on BYOD.

Pros: location-independent, strong threat intelligence, modern architecture, typically bundled with ZTNA + SWG.

Cons: cost, vendor lock-in, dependent on SSE provider's threat intel quality.

The direction most modern mid-market enterprises are heading.

#Option 4: EDR-level DNS observation

Some EDR agents (CrowdStrike, SentinelOne, Microsoft Defender) observe DNS queries at the process level, regardless of DoH. You get logging and detection at the endpoint even when DoH prevents network-level visibility.

Pros: works regardless of DoH usage, includes process context (which executable made the query), good for detection.

Cons: detection only, not blocking at the query level. Blocking needs supplementary controls.

Best used in combination with option 2 or 3 for defense-in-depth.

#The specific malware case

Malware in 2025-2026 increasingly uses DoH to evade DNS-based detection. The technique:

1. Malware drops on endpoint
2. Malware's C2 communication uses DoH to resolve C2 domain
3. DoH query goes directly to a public resolver over encrypted HTTPS
4. Corporate DNS security stack never sees the query
5. C2 communication proceeds normally

Observed families using DoH:

• Several Cobalt Strike variants
• RedLine and Lumma infostealer variants
• Some BumbleBee loaders
• Increasingly common in living-off-the-land attacks using PowerShell's native DoH capability

Detection strategies:

• Network-level TLS fingerprinting to identify the characteristic pattern of DoH requests (works but requires deep packet inspection)
• EDR process telemetry showing unexpected processes making DNS or HTTPS resolutions
• Baseline analysis of connections to known DoH endpoints from unusual processes

#For small / mid-market organizations

If you've under 100 employees and limited security budget:

Simplest effective approach: deploy Cloudflare One free tier (up to 50 users) or NextDNS business plan ($30-50/month for small teams). Push configuration to all endpoints via MDM or manual setup. Block public DoH at the perimeter if you've a firewall capable of it. Accept that BYOD and personal apps are outside scope.

This buys you:

• DNS filtering with commercial threat intelligence
• Logs of queries for investigation
• DoH-enabled so the internal network still has encrypted DNS
• Works on and off the corporate network via the agent

Budget: $0-$2K/year for a 50-person team. Order of magnitude less than enterprise approaches.

#For larger enterprises

For 500+ employees in compliance-heavy industries:

• Deploy an SSE platform (Cloudflare One, Zscaler, Netskope, Palo Alto Prisma) with integrated DNS filtering
• Force agents on all managed endpoints
• Block public DoH at egress to catch anything that bypasses the agent
• Integrate EDR DNS telemetry into SIEM for detection
• Monthly review of DoH evasion attempts and policy tuning

Budget: included in SSE platform costs ($8-25/user/month typical).

#Compliance implications

• HIPAA: DNS logs containing patient portal queries are technically in scope. Encryption of DNS queries (DoH) helps satisfy 164.312(e)(1) transmission security requirement. Logging and retention still needed.
• PCI DSS 4.0: DNS monitoring is part of Requirement 10 (logging). DoH deployment doesn't conflict with PCI. The internal resolver can still log everything.
• NIS2 (for EU-facing US companies): DNS monitoring is part of technical security measures. Same logic applies.
• CMMC / NIST 800-171: SI-4 (system monitoring) includes DNS queries. Ensure your DoH deployment produces adequate logs.

#What we look for in a DNS security engagement

• DNS architecture review. Where do queries go, what's logged, what's filtered
• DoH detection. Is DoH present on the network, which endpoints are bypassing
• Policy coverage. Are malicious domain categories being blocked, what TI feeds
• Log retention and accessibility. Can you investigate a historical query
• EDR integration. DNS telemetry flowing into SIEM
• Malware-over-DoH resilience. Would current stack detect DoH-tunneled C2
• Incident response readiness. Can the team find DNS evidence during investigation

#Resources

• Cloudflare Gateway documentation
• NextDNS enterprise documentation
• NIST SP 800-81 Secure DNS Deployment Guide (periodically updated)
• IETF RFC 8484 (DNS Queries over HTTPS specification)
• Mozilla's Trusted Recursive Resolver program

#Hire Valtik Studios

DNS security is a blind spot for most mid-market organizations now that DoH is widespread. If your DNS security stack was designed for the pre-DoH era, we run audits that identify the specific gaps and propose modernization paths. Part of most network security engagements.

Reach us at valtikstudios.com.