What is enterprise DNS security?
Enterprise DNS security is the practice of applying filtering, monitoring, and policy enforcement at the DNS layer across an organization’s entire network, covering remote workers, BYOD devices, cloud workloads, and branch offices, to prevent threats before they establish a connection.
Every device on your network, and every device your employees use off-network, makes thousands of DNS queries per day. A DNS request is the first step in any network connection: before your browser loads a page, before an app checks for updates, before malware phones home, a DNS resolver translates a domain name into an IP address. Enterprise DNS security sits at that checkpoint.
Why DNS specifically
Firewalls see packets. Endpoint agents see processes. DNS filtering sees intent: the moment a device decides to contact a domain, before the connection forms. That makes it the only control layer that can stop a threat before your network commits a single byte to it.
Enterprise DNS security goes further than consumer or SMB filtering in three ways:
- Scale and multi-site coverage: policies apply uniformly across thousands of endpoints, dozens of offices, and hybrid cloud environments from a single management plane.
- Identity-aware policy: filtering rules can be tied to user identity, device group, or network segment, not just IP range. A contractor gets different access than a sysadmin.
- Logging and audit trail: every DNS query is logged, exportable to your SIEM, and available for forensic investigation. This audit trail is essential for SOC 2, HIPAA, and incident response.
Enterprise DNS security is sometimes called protective DNS, DNS filtering for business, or DNS security gateway. These terms describe the same mechanism. The distinction from home or SMB filtering is in policy granularity, management architecture, and compliance posture.
For a foundational look at how DNS filtering works at any scale, see the complete DNS filtering guide. For cloud-specific deployments, see DNS filtering for cloud environments.
How enterprise DNS threats work
DNS is the oldest protocol on the internet and was designed in 1983 with no security model. Every network stack since has inherited it, which means every enterprise network carries a vast, queryable surface that most security tools leave largely unmonitored.
DNS threats at the network layer
Malware command-and-control
Ransomware and APTs establish communication with attacker infrastructure via DNS. The malware is already on the endpoint when this happens; DNS filtering catches the outbound call before any data moves.
DNS tunneling
Attackers embed data inside DNS query strings to exfiltrate information over a channel most firewalls pass without inspection. A properly monitored resolver detects the anomalous query patterns and blocks them.
Fast-flux and DGAs
Malware cycles through thousands of auto-generated domain names to evade blocklists. Threat-intelligence-backed filtering identifies DGA patterns in real time, blocking domains that haven’t appeared on any list yet.
Phishing and BEC
Lookalike domains targeting enterprise credentials resolve through DNS before the user sees a login page. Blocking at DNS is faster than browser-level warnings and catches every device, not just managed ones.
Shadow IT and unauthorized SaaS
Employees accessing unsanctioned cloud apps create data governance and compliance exposure. DNS logs surface every domain a device queries, giving security teams visibility into apps IT never approved.
DNS hijacking and cache poisoning
Attackers manipulate DNS responses to redirect traffic from legitimate domains to attacker-controlled servers. DNSSEC validation and encrypted DNS protocols (DoH, DoT) address this class of threat.
Endpoint security alone is insufficient
- Doesn’t protect unmanaged or BYOD devices
- Fires after malware executes, not before
- No visibility into IoT sensors or OT systems
- Agent deployment gaps in contractor environments
- Expensive to remediate after the fact
What DNS security adds
- Covers every device on the network agentlessly
- Blocks at the connection attempt, not after execution
- Single policy plane across managed and unmanaged endpoints
- Full query log for every device, every domain
- Fraction of the cost of breach response
For a deeper look at the malware threat environment, see the malware defense at the DNS layer guide. For tunneling and advanced exfiltration techniques, see DNS in cybersecurity. Related reading: DNS tunneling, DNS hijacking, the DNSSEC guide and encrypted DNS protocols.
Enterprise DNS security architecture
Most enterprises run one of three DNS security architectures, or a hybrid of all three. Understanding which fits your environment determines which service makes sense and what the rollout actually looks like.
Cloud-delivered DNS filtering
Replace your existing resolvers with a cloud-based DNS security service. Devices query the service’s resolvers directly: on-network via router or DHCP configuration, off-network via a lightweight agent or device-level DoH/DoT profile. All filtering, logging, and policy management happens in the cloud.
Best for: distributed workforces, cloud-first environments, teams without on-prem infrastructure to maintain.
Control D deployment model: point resolvers at Control D endpoints per profile. No hardware. No agents for on-network devices. Off-network users add a DNS profile to their OS or use the lightweight client.
On-premises DNS security gateway
A DNS security appliance or software sits inside your network perimeter and intercepts all internal DNS traffic. Common in highly regulated industries, air-gapped environments, or organizations with strict data residency requirements.
Best for: financial services, healthcare, government, and environments where queries cannot leave the perimeter.
Worth noting: on-prem deployments require hardware procurement, ongoing maintenance, and capacity planning. Cloud-delivered services have largely replaced this model for all but the most regulated environments.
Hybrid: cloud policy, on-prem forwarding
On-prem DNS servers forward queries to a cloud security service for policy enforcement, then return answers to internal clients. Maintains existing internal DNS infrastructure while adding cloud-scale threat intelligence and filtering.
Best for: large enterprises with existing Infoblox, Windows DNS, or BIND infrastructure who need incremental adoption without a full cutover.
Protocol layer: encrypting DNS in the enterprise
Legacy DNS (Do53) sends every query in plaintext on port 53. Anyone on the network path, including your ISP, can see every domain queried. Modern enterprise deployments should enforce encrypted DNS:
- DNS over HTTPS (DoH): port 443, works through most firewalls, used by Chrome and Firefox by default.
- DNS over TLS (DoT): dedicated TLS tunnel on port 853, preferred for OS-level and mobile deployments.
- DNS over QUIC (DoQ): lower latency than DoT on unreliable connections, supported by Control D.
Control D supports all three. For a full protocol comparison, see What is DNS over HTTPS? and the DoH vs. DoT guide.
SIEM and log pipeline integration
Enterprise DNS security without log export is incomplete. Security operations teams need DNS query logs feeding into their SIEM for correlation with endpoint and network events. Key integration points:
- Export DNS logs to Splunk or Microsoft Sentinel via Control D’s native SIEM streaming. For other SIEMs, stream raw logs to S3-compatible storage as an intermediary.
- Correlate DNS anomalies (DGA patterns, high-volume queries, new domain lookups) with firewall and EDR alerts.
- Use DNS logs to establish behavioral baselines and flag deviations in device query patterns.
- Retain logs for compliance audit windows. PCI DSS requires a minimum of 1 year. HIPAA does not specify a retention period, but most auditors recommend at least 6 years to align with the policy retention requirement. Confirm requirements with your compliance team.
See the DNS logging best practices guide for SIEM integration patterns.
Zero trust and DNS: how they connect
Zero trust network access (ZTNA) is the dominant enterprise security framework for the post-perimeter era. The core principle is never trust, always verify: no device, user, or network segment is inherently trusted, even inside the corporate network. DNS sits at the foundation of zero trust in two ways.
DNS as a zero trust enforcement point
In a zero trust model, access to any resource requires verification. DNS filtering enforces this at the connection layer: before a device can reach any internal or external resource, its DNS query is evaluated against identity-aware policy. A device that hasn’t passed posture checks or a user who lacks access to a resource gets a block at DNS, before any network traffic flows.
This is particularly important for:
- Lateral movement prevention: infected endpoints trying to reach internal resources get blocked at DNS before they can pivot.
- Microsegmentation enforcement: DNS policy per device group means a developer workstation cannot query finance system domains by default.
- Remote access: whether users are on VPN, ZTNA, or connecting directly to the internet, Control D applies the same DNS policy. Protection follows the device, not the network perimeter.
DNS over HTTPS and zero trust visibility
DoH creates a visibility problem for zero trust implementations: when browsers or devices send encrypted DNS over port 443, traditional network inspection tools can’t see the queries. The fix is to route DNS-over-HTTPS to a resolver you control, such as Control D, rather than letting devices use arbitrary DoH providers like Google or Cloudflare.
Zero trust DNS checklist for IT teams
- 1.Replace default resolvers with Control D. Each profile gets a unique resolver endpoint, so policy assignment is automatic at the DNS level.
- 2.Block outbound DNS on ports 53 and 853 at the firewall to prevent bypass.
- 3.Enforce DoH to your controlled resolver via MDM/GPO to eliminate rogue DoH use.
- 4.Enable per-device or per-group policies tied to identity and posture.
- 5.Feed DNS logs to SIEM for cross-correlation with EDR and network telemetry.
- 6.Review the shadow IT report monthly: DNS logs reveal unsanctioned SaaS before it becomes a compliance issue.
For a full overview of the zero trust framework and how DNS fits, see the what is zero trust security guide. For a Cloudflare Zero Trust pricing comparison, see the Cloudflare Zero Trust pricing guide.
Compliance use cases: CIPA, HIPAA, SOC 2, GDPR
DNS filtering shows up in the control frameworks of every major enterprise compliance standard. In most cases it is not explicitly required, but it is the most practical way to satisfy controls that would otherwise require far more expensive or complex tooling.
CIPA
CIPA requires schools and libraries receiving federal E-rate funding to block obscene, harmful, or child-endangering content. Control D’s content categories cover the required blocks out of the box, with audit logs for E-rate compliance reviews. See the school content filtering guide for deployment detail.
HIPAA
HIPAA requires covered entities to protect electronic protected health information (ePHI) from unauthorized access and disclosure. DNS filtering contributes to several Technical Safeguard controls:
- Access control (§164.312(a)(1)): DNS policy prevents unauthorized devices from reaching ePHI systems by blocking queries to those domains from uncredentialed device groups.
- Audit controls (§164.312(b)): DNS query logs provide a record of every domain accessed by every device, exportable for compliance audits.
- Transmission security (§164.312(e)(1)): encrypted DNS (DoH/DoT) prevents query interception in transit, reducing the risk of metadata exposure.
- Malware prevention: healthcare is the most targeted sector for ransomware. DNS blocking C2 domains and phishing infrastructure is a frontline control.
SOC 2
SOC 2 Trust Service Criteria require organizations to demonstrate logical access controls, monitoring, and incident response capability. DNS filtering maps to several criteria:
- CC6.1 (Logical access): DNS policy restricts access to resources based on device and user identity.
- CC6.6 (Threat detection): DNS anomaly detection and malware blocking satisfy threat monitoring requirements.
- CC7.2 (Monitoring): continuous DNS query logging provides the audit evidence auditors look for.
For a detailed mapping, read the full guide on how DNS filtering supports SOC 2 compliance.
GDPR / data residency
GDPR requires organizations processing EU personal data to maintain appropriate technical and organizational measures. DNS logging creates a data question: query logs contain device identifiers and browsing metadata. Key considerations:
- Store DNS query logs in a region that satisfies your data residency requirements.
- Control D offers 3 data storage regions across all plans, with custom dedicated regions available at additional cost for SMB and Enterprise tiers. See docs.controld.com/docs/analytics-levels for details.
- Review the DPA (Data Processing Agreement) with your DNS provider if EU employee query data is logged.
For compliance-focused deployment guidance across all frameworks, see the DNS security best practices guide.
Enterprise DNS service comparison
The five most commonly evaluated enterprise DNS security services in 2026: capabilities, limitations, and fit by deployment type. Linked vendor names lead to a full head-to-head comparison post.
| Feature | Control D | Cisco Umbrella | Zscaler | Infoblox | DNSFilter |
|---|---|---|---|---|---|
| Deployment & setup | |||||
| Agentless setup | Partial | ||||
| Time to deploy | ~5 min | 2–4 hrs | Days | Days–weeks | ~30 min |
| On-prem option | Cloud-first | Cloud-first | |||
| Security & filtering | |||||
| Malware block rate | 99.98%* | Not pub. | Not pub. | Not pub. | Not pub. |
| AI / threat intel | |||||
| Zero trust DNS † | Via DDI platform | Limited | |||
| Traffic redirection | |||||
| Enterprise management | |||||
| SIEM integration | Add-on ($0.25/user/mo) | ||||
| Per-device profiles | Unlimited | Limited | Role-based | Policy-based | |
| Full REST API | Pro+ only | ||||
| Multi-tenant mgmt | Add-on | Add-on | Add-on | Add-on | |
| Compliance & logging | |||||
| Audit log export | Add-on ($0.25/user/mo) | ||||
| CIPA / HIPAA / SOC 2 | |||||
| Encrypted DNS (DoH/DoT/DoQ) | DoH/DoT | DoH/DoT | DoH/DoT | ||
| Pricing | |||||
| Free tier | 14-day trial | 14-day trial | 14-day trial | 14-day trial | |
| Starting price | $2/endpoint/mo (SMB) · Enterprise: contact sales | Quote only | Quote only | Quote only · token-based | $1/user/mo (Basic) |
† ‘Zero trust DNS’: policy enforcement at the DNS layer tied to device identity or group, blocking lateral movement and enforcing least-privilege access before any network connection forms.
* Source: Nexxwave public DNS malware filter benchmark, June 2025 (most recent published figure). No other vendor in this table publishes an independently verified malware block rate. Always verify current information on each vendor’s site.
Looking for alternatives to a specific vendor? Cisco Umbrella alternatives · Infoblox vs. BlueCat · Cloudflare Zero Trust pricing · Best enterprise web filtering software.
How to deploy Control D across an enterprise
Control D is operational in under five minutes. Enterprise-wide rollout follows the same steps at scale, with the API handling programmatic provisioning.
Define your Profile architecture
A Profile is a bundle of filtering rules unique to Control D. Each Profile has its own resolver endpoint, filtering rules, and analytics. Design your hierarchy before provisioning. Common enterprise patterns:
- By department: Engineering, HR, Finance, and Guest, each with different content category permissions.
- By device type: managed endpoints, BYOD, IoT/OT, and servers, each with different threat categories and logging levels.
- By location: headquarters, branches, and remote workers, with regional policy variations applied as needed.
Create Profiles in the Control D dashboard or via the REST API. The API is the right path for enterprises provisioning more than ~20 Profiles.
Deploy resolvers
Point devices at Control D’s resolver endpoints for their assigned Profile. Four deployment paths:
- Router/DHCP (on-network): set Control D resolver IPs at the router or DHCP server. Every device on the network gets filtered without individual configuration.
- MDM/GPO (managed endpoints): push DNS profile configurations to managed Windows, Mac, iOS, and Android devices via your MDM (Jamf, Intune, Kandji) or Group Policy.
- OS-level DoH/DoT: configure encrypted DNS profiles at the OS level for devices that need off-network filtering without an agent.
- API-provisioned: for MSPs or large IT teams managing hundreds of distinct client or department deployments, use the Control D Org API to provision profiles, endpoints, and policies programmatically.
Firewall DNS lockdown
Block outbound DNS on ports 53 and 853 to any IP except your Control D resolver endpoints. Because each Control D Profile has a unique resolver address, this lockdown is straightforward to configure and verify in your firewall logs. This step is required for any enterprise deployment where compliance or policy enforcement matters.
Connect to your SIEM
Export DNS query logs to your SIEM for security correlation and compliance audit evidence. Control D includes SIEM streaming to Splunk and Microsoft Sentinel on all plans, with raw query logs retained for 30 days in-platform. For longer retention, stream logs to your SIEM or S3-compatible storage. PCI DSS requires a minimum of 1 year. For HIPAA, most auditors recommend retaining logs for at least 6 years to align with the broader policy retention standard, though this should be confirmed with your compliance team.
Review analytics and tune
The Control D analytics dashboard shows every DNS query in real time: device, domain, category, outcome, and the specific profile rule that triggered the action. In the first 30 days:
- Review the shadow IT report to see every unsanctioned SaaS domain your devices are reaching.
- Identify devices with anomalous query volumes or patterns.
- Tune any false-positive blocks that are interrupting business-critical applications.
- Validate that the firewall DNS lockdown is working (no queries reaching external resolvers).
Enterprise or managing large deployments?
The Control D Org API gives full programmatic control over provisioning, profiles, and reporting. Ideal for IT teams managing multi-site rollouts and MSPs handling enterprise clients. See docs.controld.com/docs/org-api.
Control D is SOC 2, ISO 27001, and ISO 27701 certified. See controld.com/compliance.
