DNS Security for Enterprise: DNSSEC, DoH, RPZ, and Exfiltration Detection
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
DNS is the backbone of internet communication and the protocol attackers trust most. It traverses almost every firewall rule, gets logged almost nowhere by default, and is used by malware for everything from initial C2 check-in to long-term data exfiltration to phishing infrastructure. An enterprise that cannot see its own DNS traffic is flying blind. This guide covers the four pillars of enterprise DNS security: validating response integrity with DNSSEC, enforcing resolution policy with RPZ, detecting tunneling and beaconing in DNS logs, and managing DNS over HTTPS to maintain visibility without sacrificing privacy.
Pillar 1: DNS Logging, See Everything First
Before any detection or blocking is possible, you need complete DNS query logs. Most enterprise networks log almost no DNS traffic by default.
Enable query logging on your resolver
BIND: add `querylog yes;` to the options block in named.conf. Unbound: set `log-queries: yes` in unbound.conf. Windows DNS Server: dnscmd /Config /LogLevel 0xFFFF (log all queries and responses). For cloud-native resolvers: AWS Route 53 Resolver Query Logging (enable in Route 53 console or via CLI); GCP Cloud DNS logging (per-zone logging enabled via API); Cloudflare Gateway DNS logs (automatic with Zero Trust deployment).
Ship DNS logs to your SIEM
DNS query logs are high-volume, a 500-person organization generates 5-20 million DNS queries per day. Use a dedicated data pipeline: Filebeat with the DNS module, or the dns module in Elastic Agent, or Cribl Stream for volume reduction before indexing. Key fields to index: timestamp, client IP, query name (FQDN), query type (A, AAAA, TXT, MX, etc.), response code (NOERROR, NXDOMAIN, SERVFAIL), and response IP.
Cloudflare Gateway for DNS visibility with zero infrastructure
Cloudflare Gateway's DNS resolver (1.1.1.3 for families, or your assigned Gateway DoH endpoint) logs every DNS query, shows the resolution result, and lets you apply policies without managing a resolver. With WARP enrolled devices, all DNS is routed through Gateway. Configure a log retention period and enable Logpush to ship to your SIEM. This eliminates the need for internal resolver log infrastructure for remote and cloud-first environments.
Pillar 2: Response Policy Zones for Blocking
RPZ lets your resolver block or redirect requests for malicious domains before the client ever makes a connection, at the DNS level, with no network changes required.
Ingest a commercial threat intelligence RPZ feed
Commercial RPZ feeds include: Infoblox (DNS Firewall), Cisco Umbrella (integrated resolver), SURBL (spam/malware domains), and CINS Army (active threat IPs). For open-source options: the Spamhaus Domain Block List (DBL) and the Abuse.ch DNS Block List (DNSBL) are available as RPZ-compatible zone files. Configure your BIND or Unbound resolver to transfer the zone from the feed provider and refresh every 30-60 minutes.
BIND RPZ configuration example
In named.conf: response-policy { zone "rpz.yourthreatfeed.com"; }; In the RPZ zone: *.maliciousdomain.com CNAME rpz-nxdomain., this returns NXDOMAIN for any subdomain of maliciousdomain.com. Use rpz-passthru for explicit allowlist entries that should bypass RPZ blocking. Log all RPZ hits: these are high-signal, any client querying a known-malicious domain warrants investigation.
Sinkhole vs NXDOMAIN response
For most blocked domains, returning NXDOMAIN is sufficient and simpler. For C2 detection, sinkholing (returning a controlled IP that you run an HTTP listener on) generates richer data, you can see the malware's HTTP callbacks including User-Agent, URI patterns, and POST bodies. Run a sinkhole listener using an nginx instance logging all requests, and alert when any internal IP connects to your sinkhole address.
Build internal RPZ for phishing domains
Maintain an internal RPZ zone for domains that are typosquats or lookalikes of your own company domains. Monitor Certificate Transparency logs (via crt.sh or Facebook CT Monitor) for new certificates issued for domains that resemble your organization name. Add each finding to your internal RPZ within 24 hours of detection, before attackers can use the infrastructure for phishing campaigns targeting your employees.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Pillar 3: DNS Tunneling and C2 Beaconing Detection
DNS-based C2 and exfiltration have distinct signatures in query logs. These detection rules catch the most common patterns.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Pillar 4: DNSSEC and DoH Policy
DNSSEC validates that DNS responses come from the authoritative source and were not tampered with. DoH policy maintains your visibility while protecting query confidentiality.
Enable DNSSEC validation on your resolver
For BIND: add `dnssec-validation auto;` to the options block. This enables automatic trust anchor management using RFC 5011 for the root zone. Verify: dig +dnssec google.com from a client behind your resolver, you should see the AD (Authenticated Data) flag in the response. Test DNSSEC failure handling: dig +dnssec sigfail.verteiltesysteme.net should return SERVFAIL (validation failure), not an A record.
Block DoH endpoints at the network level
Create firewall rules or DNS RPZ entries blocking the well-known DoH resolver IPs: 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 149.112.112.112 on port 443. This forces all DNS through your internal resolver for managed devices. Add DNS CNAME RPZ entries for dns.cloudflare.com, dns.google, dns.quad9.net to return NXDOMAIN. Note: this is only effective on managed corporate devices, BYOD devices using their own internet connection are outside your control.
Provide a corporate DoH endpoint
After blocking public DoH, provide an encrypted alternative. Cloudflare Gateway allows you to configure a custom DoH endpoint (https://your-org.cloudflare-gateway.com/dns-query) that encrypts queries while maintaining full logging and RPZ policy enforcement. Configure this as the DoH endpoint in your WARP client profiles so devices use encrypted DNS without bypassing your security controls.
The bottom line
DNS logging is the single highest-ROI security investment for threat detection that most organizations have not made. Turn on query logging on your resolver this week, it costs nothing and immediately gives you visibility into C2 beaconing, tunneling, and phishing infrastructure that is currently invisible. Add an RPZ feed from a threat intelligence provider for blocking. Then build the four SIEM rules for tunneling and beaconing. DNS is where 91% of malware phones home, if you cannot see it, you cannot detect it.
Frequently asked questions
What is DNS tunneling and how does it work?
DNS tunneling encodes arbitrary data inside DNS query and response records, typically TXT, CNAME, or A records. A malware client encodes its data as subdomains of an attacker-controlled domain (e.g., base64-encoded-data.c2.attacker.com) and sends a DNS lookup. The attacker's authoritative DNS server decodes the subdomain, processes the data, and returns encoded instructions in the DNS response. Because DNS queries are almost universally permitted outbound, even in networks with strict firewall rules, tunneling is a reliable C2 and exfiltration channel.
What is the difference between DNSSEC and DNS over HTTPS?
DNSSEC (DNS Security Extensions) authenticates DNS responses using cryptographic signatures, it prevents DNS spoofing and cache poisoning by verifying that responses came from the authoritative server and were not tampered with in transit. It does not encrypt DNS queries. DNS over HTTPS (DoH) encrypts DNS queries between the client and the resolver, preventing eavesdropping and man-in-the-middle interception. They solve different problems: DNSSEC = response integrity; DoH = query confidentiality.
Should I block DNS over HTTPS in my enterprise network?
Yes, for managed enterprise devices. DoH routes DNS queries to a third-party resolver (Cloudflare 1.1.1.1, Google 8.8.8.8) over HTTPS, bypassing your internal DNS resolver and its logging, filtering, and RPZ policies. Block DoH at the network level by blackholing the well-known DoH resolver IPs (1.1.1.1:443, 8.8.8.8:443 for DNS specifically) and by blocking common DoH hostnames in your proxy. Then provide a corporate DoH endpoint using Cloudflare Gateway or your resolver that encrypts DNS while maintaining visibility.
What is a Response Policy Zone (RPZ) and how is it different from a DNS blocklist?
An RPZ is a DNS zone file that contains overriding responses for specific domain names or patterns. When a DNS query matches an RPZ entry, the resolver returns a configured response (NXDOMAIN, a sinkhole IP, or a custom address) instead of the real answer. RPZ is implemented inside your resolver (BIND, Unbound, PowerDNS) and is more flexible and performant than external blocklists. Commercial threat intelligence feeds (Infoblox, Cisco Umbrella, SURBL) provide RPZ zone files that can be ingested directly into your resolver.
How do I enforce enterprise DNS security when users enable private DNS on their phones?
Users enabling private DNS (DNS-over-HTTPS or DNS-over-TLS on Android/iOS) bypass corporate DNS controls by routing queries to public resolvers like Cloudflare (1.1.1.1) or Google (8.8.8.8). For corporate-managed devices: use MDM (Intune, Jamf) to push a managed DNS profile pointing to your corporate resolver and disable user access to private DNS settings. For BYOD and contractor devices accessing corporate resources via ZTNA: configure your ZTNA gateway (Cloudflare Access, Zscaler) to route DNS queries through a secure DNS resolver that enforces filtering policies — this intercepts DNS regardless of what is configured on the device. For network-level enforcement: block outbound traffic to port 853 (DoT) and known DoH endpoints to force DNS back to your controlled resolver.
What DNS query anomalies should trigger an immediate SOC investigation rather than just an alert?
Escalate to immediate investigation rather than queued alert for any of these DNS patterns: a single internal host generating more than 500 NXDOMAIN responses within 10 minutes (DGA malware active C2 seeding), any DNS TXT query from an internal workstation to a domain registered within the past 72 hours (active exfiltration window matches attacker staging timelines), a query containing a base64-encoded string longer than 40 characters as a subdomain label (manual tunneling or automated exfiltration tool), any internal host querying a known sinkholed domain that your DNS security feed confirms as active malware C2 infrastructure, and DNS queries to the same domain from more than 50 distinct internal hosts within 30 minutes (worm propagation or malicious update distribution). These patterns differ from threshold-based alerting because each represents a narrow behavior window where attacker dwell time is actively compressing. Delayed investigation by even 30 minutes meaningfully increases the scope of a containment action.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.