What is DNS security? Definition, examples, and how it works are questions that every IT professional must be able to answer as DNS-based threats continue to escalate. DNS over HTTPS (DoH) represents one of the most significant shifts in how we protect domain name resolution from eavesdropping and manipulation. Traditional DNS queries travel in plaintext, exposing every website visit, API call, and service lookup to anyone positioned between the client and the resolver.
DoH wraps those queries inside encrypted HTTPS connections, making them indistinguishable from regular web traffic. For security teams, this changes the monitoring landscape dramatically. This guide walks you through practical steps to understand, implement, and manage DoH in enterprise environments. Whether you are evaluating DoH for the first time or refining an existing deployment, these steps will give you concrete, actionable direction.
Key Takeaways
- DoH encrypts DNS queries inside HTTPS, preventing passive surveillance of domain lookups.
- Enterprise deployment requires careful resolver selection and network policy configuration.
- DoH can bypass traditional DNS-based security controls if left unmanaged.
- Split-horizon DNS and internal zones need special handling under DoH policies.
- Monitoring encrypted DNS traffic demands new tooling and updated incident response playbooks.
1. Understand How DoH Works and Why It Matters
Traditional DNS vs. DoH
Standard DNS uses UDP port 53 to send queries and receive responses in plaintext. Any network device along the path, from your local router to an ISP's infrastructure, can read, log, or modify these packets. This is not a theoretical risk; ISPs in multiple countries have been documented injecting ads or redirecting queries for revenue. Man-in-the-middle attacks on DNS remain one of the simplest vectors for phishing and credential theft in corporate environments.
DoH changes this by sending DNS queries as HTTPS POST or GET requests to a compatible resolver, typically over TCP port 443. The query content is encrypted with TLS, so intermediary devices see only the destination IP of the resolver. From a packet inspection standpoint, DoH traffic looks identical to any other HTTPS session. This makes it extremely difficult for passive observers to determine which domains a user is resolving.
Where DoH Fits in DNS Security
Understanding what DNS security means, including its definition, examples, and how it works, provides the foundation for evaluating DoH properly. DoH is not a replacement for DNS security; it is one layer within a broader strategy. It protects the confidentiality and integrity of query traffic, but it does not validate whether the resolved IP address is legitimate. DNSSEC handles that authentication layer separately.
The real value of DoH for security professionals is preventing passive reconnaissance. Attackers who compromise a network segment can no longer trivially harvest DNS logs to map internal activity. However, DoH also introduces blind spots for defenders who rely on DNS query inspection for threat detection. That tension between privacy and visibility defines most enterprise DoH discussions today.
2. Choose and Configure Your DoH Resolver
Evaluating Public vs. Private Resolvers
The resolver you select determines who can see your decrypted DNS queries. Public resolvers like Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) all support DoH, but each has different privacy policies, logging practices, and filtering capabilities. Quad9, for example, blocks known malicious domains by default. Cloudflare publishes regular transparency reports and commits to purging query logs within 24 hours. Google retains anonymized data for longer periods.
For enterprises, running a private DoH resolver offers the most control. Solutions like Unbound, BIND 9.17+, or commercial DNS firewalls can serve DoH endpoints internally. This keeps decrypted queries within your infrastructure, allows integration with SIEM platforms, and lets you enforce custom blocklists. The tradeoff is operational overhead: you need to manage TLS certificates, handle failover, and maintain the resolver infrastructure yourself.
Client Configuration Steps
Configuring DoH varies by operating system and browser. Firefox was the first browser to enable DoH by default (using Cloudflare) for U.S. users. In Firefox, navigate to Settings, then Network Settings, and enable DNS over HTTPS with your preferred provider. Chrome uses the system resolver's DoH endpoint if available; you can force it via chrome://flags/#dns-over-https. Windows 11 supports DoH natively in network adapter settings when you specify a known DoH-capable DNS server.
On Linux systems, the systemd-resolved service supports DoH through the DNSOverTLS directive, though pure DoH requires additional tooling like dnscrypt-proxy or cloudflared running as a local proxy. For macOS, configuring a DoH profile through a .mobileconfig file is the cleanest approach, and it works across all applications rather than just browsers. Test your configuration by visiting a DoH test page or querying dig against your resolver to confirm encrypted transport.
Deploy DoH configuration through MDM or Group Policy to maintain consistency across your fleet and prevent users from selecting unauthorized resolvers.
3. Manage DoH in Enterprise Networks
Policy Enforcement Strategies
The biggest enterprise concern with DoH is shadow DNS: applications or browsers using external DoH resolvers that bypass your corporate DNS infrastructure. When a user's browser sends queries directly to Cloudflare or Google over HTTPS, your DNS-based security filters, content policies, and logging systems become blind. Firefox respects a canary domain (use-application-dns.net) that, if it returns NXDOMAIN from your internal resolver, disables the browser's built-in DoH. This is your first line of defense.
Beyond the canary domain, consider blocking known public DoH resolver IPs at the firewall level. Maintain an updated list of endpoints for major providers. Some next-generation firewalls can identify DoH traffic through TLS fingerprinting or SNI inspection, even when the destination IP is unfamiliar. Combine this with endpoint policies that restrict which applications can modify DNS settings. Group Policy for Windows and MDM profiles for macOS and iOS give you granular control.
Organizations managing identity provider security and user experience already understand the balance between protection and usability. The same principle applies here: you want encrypted DNS for privacy, but not at the cost of losing security visibility. A managed DoH deployment, where you control the resolver, gives you both.
Also Check: SEO Audit Checklist to Improve Domain Strength
Unmanaged DoH can allow malware to exfiltrate data through encrypted DNS channels that your existing security tools cannot inspect.
Handling Internal DNS Zones
Split-horizon DNS is common in enterprises, where internal domains like corp.example.com resolve differently inside and outside the network. If a client uses an external DoH resolver, internal-only records will fail to resolve. This breaks access to intranet sites, internal APIs, and private services. Your DoH deployment must account for this by configuring clients to use DoH only for external queries, or by running an internal DoH resolver that handles both internal and external zones.
The recommended approach is to deploy an internal DoH endpoint that acts as a forwarding resolver. It answers queries for your private zones directly and forwards everything else to a trusted upstream DoH provider. Tools like CoreDNS support this split routing natively. Document your zone topology carefully, because any misconfiguration can silently break service discovery in microservices architectures or Kubernetes clusters that depend on internal DNS.
Some VPN clients override DNS settings when connected, potentially conflicting with DoH configurations. Test VPN and DoH interactions thoroughly before rolling out to production.
4. Monitor and Troubleshoot DoH Traffic
Visibility Challenges
DNS query logging has been a cornerstone of network security for decades. Security teams use it to detect command-and-control callbacks, data exfiltration through DNS tunneling, and domain generation algorithm (DGA) activity. When queries move to DoH, traditional network taps and packet captures on port 53 become useless. If your monitoring strategy relies solely on network-level DNS inspection, DoH will create a significant blind spot that attackers can and will exploit.
The solution is to shift logging from the network layer to the resolver layer. If you operate your own DoH resolver, you have full access to query logs. Pipe these logs into your SIEM alongside your other security telemetry. Commercial DNS security platforms from vendors like Infoblox, Cisco Umbrella, and Palo Alto Networks already support DoH-aware logging. The key is to treat your managed DoH resolver as the single source of truth for DNS activity, not the network wire.
"Encrypted DNS does not eliminate visibility; it moves the observation point from the network to the resolver."
Building a Detection Framework
Start by establishing a baseline of normal DNS query patterns for your environment. Track metrics like queries per second per client, unique domains queried per hour, and the ratio of NXDOMAIN responses. Anomalies in these patterns often indicate compromise, regardless of whether queries travel over plaintext DNS or DoH. Machine learning models trained on your baseline data can flag unusual activity faster than static threshold alerts.
For DoH-specific detection, monitor outbound HTTPS connections to known DoH resolver IPs from hosts that should not be using them. Create firewall rules that log, rather than block, these connections initially so you can assess the scope of unauthorized DoH usage. Endpoint detection and response (EDR) tools can identify processes that establish DoH connections, giving you application-level attribution. Combine network, resolver, and endpoint signals for a comprehensive detection posture that covers DNS security across all transport methods.
Use threat intelligence feeds that include DoH-specific indicators of compromise, such as malicious domains served through encrypted resolvers.
Final Thoughts
DNS over HTTPS is not optional for modern security architectures; it is an operational reality that demands active management. The protocol delivers genuine privacy improvements by encrypting queries that were previously exposed to every network hop. But it also requires security teams to rethink their monitoring strategies and invest in resolver-level visibility.
Deploying managed DoH endpoints, enforcing client policies, and integrating encrypted DNS logs into your SIEM will let you maintain the security controls your organization needs while respecting user privacy. Treat DoH as a tool to be governed, not a threat to be feared.
Disclaimer: Portions of this content may have been generated using AI tools to enhance clarity and brevity. While reviewed by a human, independent verification is encouraged.
