DNS over HTTPS (DoH) encrypts DNS queries inside standard HTTPS traffic on port 443. It was designed to protect user privacy by preventing ISPs and network operators from observing DNS queries. However, the same encryption that protects privacy also blinds security teams to DNS-based threats. Attackers use DoH to bypass DNS monitoring, exfiltrate data through encrypted channels, and establish command-and-control communications that are indistinguishable from normal web traffic.
This is a genuine tension between privacy and security. DoH is not inherently malicious — it solves real privacy problems. But the security implications of making DNS invisible to network monitoring are significant, and attackers have been quick to exploit them.
How DNS Over HTTPS Works
Traditional DNS sends queries and responses in plaintext over UDP port 53. Anyone on the network path (ISPs, network administrators, middleboxes) can observe and potentially modify these queries. You can inspect DNS records for any domain to see what standard DNS resolution reveals.
DoH wraps DNS queries inside HTTPS:
Traditional DNS:
Client → UDP:53 → DNS Resolver
(Visible to network monitoring)
DNS over HTTPS:
Client → HTTPS:443 → DoH Resolver (e.g., https://dns.google/dns-query)
(Encrypted, indistinguishable from normal HTTPS traffic)
The DNS query is sent as an HTTP POST or GET request to a DoH resolver endpoint. The response comes back as an HTTP response. The entire exchange is encrypted with TLS, just like any other HTTPS connection.
How Attackers Abuse DoH
Bypassing DNS-Based Security Controls
Many organizations use DNS as a security enforcement point:
- Content filters block access to malicious or inappropriate domains by intercepting DNS queries
- DNS sinkholes redirect queries for known malware domains to safe IPs
- DNS monitoring detects data exfiltration, C2 communication, and policy violations
When malware on a compromised machine uses DoH instead of the network's DNS resolver, all of these controls are bypassed. The DNS query never touches the corporate resolver — it goes directly to a public DoH endpoint encrypted inside HTTPS.
Normal DNS path (monitored):
Malware → Corporate Resolver → Security Filter → Block
DoH path (bypasses monitoring):
Malware → HTTPS:443 → Public DoH Resolver → Resolve → Exfiltrate
Malware Command and Control
Several malware families have adopted DoH for their command-and-control infrastructure:
- Godlua (2019) was one of the first documented malware families using DoH for C2 resolution
- ODoH-RAT variants use Oblivious DoH for additional anonymity
- APT groups have incorporated DoH into their toolkits to avoid DNS-based detection
The malware queries its C2 domain through DoH, receiving the current IP address of the command server. Because the query is encrypted inside HTTPS, network-level DNS monitoring never sees it.
Data Exfiltration via DoH
DoH can be used for data exfiltration in the same way as traditional DNS tunneling, but with the added advantage of encryption:
- Data is encoded in DNS query names (subdomains)
- Queries are sent through DoH to a public resolver
- The resolver forwards the query to the attacker's authoritative server
- The attacker decodes the data from the query names
Traditional DNS tunneling can be detected by analyzing query patterns (long subdomains, high entropy, unusual volume). DoH tunneling is invisible to network monitoring because the queries are encrypted.
Bypassing Content Filters
In environments with strict internet access policies (schools, workplaces, regulated industries), users or malware can use DoH to bypass content filtering:
- A user installs a browser with built-in DoH (most modern browsers support it)
- DNS queries bypass the corporate resolver entirely
- Content filters that rely on DNS interception are ineffective
This is particularly problematic in environments where DNS-based filtering is required for compliance (CIPA in schools, for example).
Why Detection Is Difficult
DoH is specifically designed to be hard to distinguish from normal HTTPS traffic:
- Same port (443) as all other HTTPS traffic
- Same TLS encryption as any web connection
- Major DoH providers (Google, Cloudflare, Quad9) also host other HTTPS services, so blocking their IPs would break legitimate functionality
- TLS SNI can reveal the DoH endpoint, but Encrypted Client Hello (ECH) is increasingly hiding this
Traditional network monitoring tools that inspect DNS on port 53 see nothing. The DNS traffic is inside HTTPS on port 443, mixed in with billions of other HTTPS connections.
How to Defend Against DoH Abuse
Block Known DoH Endpoints
Maintain a list of known public DoH resolver endpoints and block them at the firewall:
# Common DoH endpoints to consider blocking
dns.google (8.8.8.8, 8.8.4.4)
cloudflare-dns.com (1.1.1.1, 1.0.0.1)
dns.quad9.net (9.9.9.9)
doh.opendns.com
dns.nextdns.io
This is an imperfect defense because new DoH endpoints appear regularly, and DoH can be hosted on any HTTPS server. But it blocks the most commonly used resolvers.
Deploy Endpoint-Level DNS Controls
Instead of relying solely on network-level DNS monitoring, deploy controls on the endpoint itself:
- EDR (Endpoint Detection and Response) agents can monitor application-level DNS behavior regardless of whether it uses UDP port 53 or DoH
- Browser policies can force browsers to use the corporate resolver and disable built-in DoH
- Group Policy (Windows) or MDM profiles can configure DNS settings at the OS level
# Disable DoH in Firefox via enterprise policy
{
"policies": {
"DNSOverHTTPS": {
"Enabled": false,
"Locked": true
}
}
}
Use DNS over HTTPS on Your Own Terms
Deploy your own DoH resolver internally and configure clients to use it. This gives you encrypted DNS (protecting against external eavesdropping) while maintaining internal visibility:
# Example: Internal DoH resolver using dnsdist
addDOHLocal('0.0.0.0:443', '/etc/ssl/cert.pem', '/etc/ssl/key.pem', '/dns-query')
Clients send DoH queries to your internal resolver, which logs and filters them before forwarding upstream. You get both privacy from external observation and security from internal monitoring.
TLS Inspection
Where legally and ethically appropriate, TLS inspection (decryption of HTTPS traffic at a proxy) can reveal DoH queries. This is common in corporate environments with explicit notice to employees.
However, TLS inspection has significant privacy, legal, and operational implications. It requires deploying a trusted CA certificate to all managed devices and may break certificate pinning in some applications.
Monitor for DoH Indicators
Even without decrypting DoH traffic, you can look for behavioral indicators:
- Long-duration HTTPS connections to known DoH providers
- High request rates to DoH endpoints (normal browsing does not generate the same DNS query patterns as tunneling)
- Connections to DoH providers from machines that should use internal DNS (servers, IoT devices)
- Encrypted SNI (ECH) connections, which may indicate DoH with enhanced privacy
If you suspect a machine on your network is using DoH to communicate with malicious infrastructure, check the blacklist status of any suspicious IPs or domains you identify through behavioral analysis.
Mitigation Checklist
- Known public DoH endpoints are blocked or monitored at the firewall
- Browser DoH is disabled via enterprise policy on managed devices
- EDR agents monitor application-level DNS behavior on endpoints
- Internal DoH resolver deployed for authorized encrypted DNS use
- DNS policy enforcement works at both network and endpoint levels
- Monitoring detects connections to known DoH providers from unexpected sources
- HTTPS inspection deployed where legally and operationally appropriate
- Incident response procedures account for DoH-based evasion
Common Misconfigurations
- Relying solely on network-level DNS monitoring — completely blind to DoH-based evasion
- Not managing browser DNS settings — modern browsers enable DoH by default in some configurations, bypassing corporate DNS without the user or admin knowing
- Blocking DoH IPs without maintaining the blocklist — new DoH providers appear frequently; a static blocklist becomes stale
- No endpoint-level DNS controls — if the network layer is bypassed, there is no second line of defense
- Allowing all HTTPS traffic without inspection — while not all organizations can inspect TLS, those that can should include DoH detection in their inspection rules
The Privacy vs. Security Balance
It is important to acknowledge that DoH was created for legitimate privacy reasons. ISPs have been documented selling DNS query data, and unencrypted DNS is vulnerable to surveillance and manipulation. The abuse of DoH by attackers does not invalidate its privacy benefits.
The goal for security teams is not to eliminate encrypted DNS but to maintain visibility through alternative means — endpoint controls, internal DoH resolvers, and behavioral analysis — while respecting user privacy where appropriate.
Ethical Note
Testing DoH bypass techniques should only be done on networks and devices you own or are authorized to test. Using DoH to bypass content filters in environments where you have agreed to those policies (employer networks, school networks) may violate acceptable use policies. For security research, set up a controlled environment with your own DoH resolver, DNS monitoring, and test clients.
This article is part of the Complete Guide to DNS Attacks and DNS Security. See also: DNS Tunneling Attack, DNS Hijacking.