DNS Security Best Practices for Enterprise Environments

Protective DNS is the practice of routing DNS queries through a resolver that blocks resolution of malicious, C2, phishing, and newly registered domains before a connection is established. Because DNS is required for almost all internet communication, a protective DNS resolver that blocks a malicious domain prevents the associated attack regardless of whether the malware or phishing content reaches the endpoint.

CISA provides a free Protective DNS service (PDNS) for US federal agencies and state, local, tribal, and territorial governments. Commercial protective DNS services for enterprise environments include Cisco Umbrella, Palo Alto DNS Security, Cloudflare Gateway, and Akamai Secure Internet Access. Evaluation criteria: threat intelligence feed freshness (how quickly newly registered malicious domains are added to blocklists), category-based filtering granularity, the ability to allow specific domains in blocked categories, and integration with your SIEM for query logging.

For on-premises DNS infrastructure, BIND's RPZ (Response Policy Zone) feature allows you to subscribe to commercial threat intelligence feeds and block resolution of domains in those feeds at your recursive resolver. RPZ is the most flexible blocking mechanism for organizations that operate their own DNS infrastructure and want fine-grained control over block list sources and exception handling.

Do not rely exclusively on blocklist-based protective DNS. Blocklists lag DGA domains and newly registered malicious domains by hours to days. Complement blocklist filtering with behavioral analytics (described below) that detect malicious DNS patterns that have not yet been added to blocklists.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that DNS responses have not been modified in transit. DNS cache poisoning attacks — where an attacker injects malicious DNS responses that redirect legitimate domain requests to attacker-controlled IP addresses — are defeated by DNSSEC because the forged response cannot produce a valid cryptographic signature.

DNSSEC signing should be implemented for all domains your organization owns. If you register domains through a registrar that supports DNSSEC (most major registrars do), enabling signing is typically a configuration change in your DNS management console. The operational complexity of DNSSEC is in key rotation — DNSSEC keys must be rotated on a defined schedule, and the rotation process must be coordinated between your DNS hosting provider and your registrar to avoid DNSSEC validation failures during the transition.

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries between the client and resolver, preventing on-path observers from monitoring DNS query traffic. For enterprise environments, DoH and DoT present a detection challenge: encrypted DNS queries that bypass your on-premises recursive resolver eliminate the DNS query visibility that threat detection relies on. NSA guidance recommends that enterprises configure DoH to use an enterprise-controlled resolver rather than public resolvers, preserving DNS visibility while gaining query encryption. This is implemented via DNS configuration management in MDM or Group Policy — forcing all endpoints to use your internal resolver which then queries upstream using DoT.

DNS query logs are one of the highest-value threat detection data sources available because malware communicates over DNS in detectable patterns regardless of endpoint compromise state. A compromised endpoint that has disabled the EDR agent still makes DNS queries — and those queries are visible at the resolver.

Log all DNS queries from endpoints, including the source host, queried domain, query type, response, and timestamp. This requires logging at the recursive resolver (for on-premises DNS infrastructure) or collecting endpoint DNS query logs via EDR platforms that capture Sysmon DNS event ID 22 or equivalent. Ship DNS query logs to your SIEM with a retention policy of at least 90 days.

Detection analytics for DNS-based C2 beaconing exploit the behavioral regularity that automated C2 communication produces. Key detections: beaconing regularity (a host making DNS queries to the same domain or domain pattern at consistent intervals — every 30 seconds, every 5 minutes — is likely automated C2 communication rather than human browsing), high-entropy domain detection (DGA domains have measurably higher character entropy than legitimate domains — a domain with >4.0 bits of entropy per character is a DGA candidate), and DNS query volume anomaly (a host generating 50x more DNS queries than its baseline generates during normal operation is likely running malware with DGA or DNS tunneling behavior).

For DGA detection, implement a model that calculates character entropy for all queried domains and alerts on NXDOMAIN responses to high-entropy domains. DGA malware typically queries thousands of algorithmically generated domains (most of which do not resolve) in rapid succession before finding the active C2 domain. The NXDOMAIN flood from a single host querying high-entropy domains is a reliable DGA behavioral signature.

DNS tunneling uses DNS query and response payloads to encode data, allowing attackers to exfiltrate data or establish C2 channels over DNS even when all other outbound protocols are blocked. Detection relies on analyzing query characteristics that differ from legitimate DNS traffic.

DNS tunneling indicators: unusually long query names (DNS tunneling encodes data in the subdomain — a query like 'aGVsbG8gd29ybGQ.tunnel.c2domain.com' is data encoding, not a real hostname), high query volume per domain from a single host, high byte count of DNS query traffic relative to baseline, and TXT record queries to unusual domains (TXT records carry arbitrary text data and are commonly used for data transport in DNS tunneling).

Analytics that catch 90% of DNS tunneling: alert on any host querying domains where the average subdomain label length exceeds 25 characters, alert on hosts generating more than 500 DNS queries per hour to a single second-level domain, and alert on hosts querying TXT records for domains not in your approved DNS infrastructure list.

For infrastructure hardening: restrict DNS recursion to authorized internal resolvers — no workstation should be able to query external resolvers directly. If all DNS traffic flows through your internal resolvers, you have complete query visibility and can apply RPZ filtering centrally. Block outbound UDP/TCP port 53 at the perimeter firewall except from your authorized recursive resolvers. This does not block DoH (port 443) but makes traditional DNS tunneling detectable by restricting the traffic path.

DNS is simultaneously one of the most useful threat detection data sources and one of the most neglected. Organizations that collect DNS query logs, implement protective DNS filtering, and build behavioral analytics for C2 beaconing, DGA domains, and DNS tunneling patterns gain visibility into malware communication that is invisible to endpoint-only detection. The data cost is low (DNS query logs are small) and the detection value is high — if you are not collecting and analyzing DNS telemetry, you have a significant detection blind spot.