Enterprise DNS security: stop threats before the connection is made
EfficientIP’s 360° DNS Security approach secures the DNS your network already runs on. Malicious domains are blocked before resolution, exfiltration and tunnelling are caught in the query stream, and the service keeps answering while an attack is in progress.
Rated five stars for real-time DNS security in the GigaOm Radar for DDI.
The control point every attack passes through
Nearly every attack involves a name lookup. Malware resolves the domain its operator controls. A compromised host works through a list of domains generated seconds earlier. A tunnelling tool carries data out inside query payloads that a perimeter device reads as ordinary DNS traffic.
What the perimeter cannot see
Firewalls and intrusion prevention inspect the connection after resolution has already handed it an address. By then the decision has been made, and the query that made it is not in their record. A resolver reads the name while intent is still visible, including names that have never been seen before, which is where data exfiltration and DNS tunnelling become visible while they are still running.
What regulators now expect
NIS 2, DORA and GDPR each raise the bar on detection, response and reporting for the services DNS underpins, and the updated NIST guidance on DNS security gives the internal argument an external reference. An enterprise that runs its own resolvers already holds the query record those obligations ask about.
- 85% Share of cyber attacks in which malware uses DNS (EfficientIP CISO Guide to DNS Security, 2025)
- $1.1M Average damage per DNS attack incident (IDC Global DNS Threat Report, commissioned by EfficientIP)
What this changes day to day
For the security team
Threats are stopped at the point of intent rather than investigated after the fact. Domains with no reputation history, and domains generated by an algorithm minutes ago, are caught without a rule written for them in advance. Every blocked query stays in the record as evidence for the incident.
For the network team
No new inline appliance and no agent on the endpoint. The resolution path the estate already depends on stays as it is, because the security control runs on the DNS infrastructure that is already there and is operated by the people who already run it.
The network foundation gets secured without being rebuilt.
Across the whole attack lifecycle
Four stages, in the order an incident actually runs. Each one starts with what you get, then names the capability behind it and where the full detail lives.
01
Protect — block before resolution
Advanced filtering applies policy at the resolver, scoped to a client, a group or a site rather than applied as one blanket list, and managed centrally across the estate. The feeds behind it are DNS-centric rather than a general reputation list bolted on.
Outcome: users, data and applications are protected before a malicious connection is ever made, with policy scoped to the client rather than the whole estate.
02
Detect — find what has no signature yet
Traffic inspection and user behavioural analysis run against the live query stream, with algorithmic detection aimed at zero-day threats, generated domains, phishing, tunnelling, exfiltration and command-and-control traffic. Nothing here waits for a signature to be published.
Outcome: zero-day domains, DNS tunnelling, data exfiltration and generated-domain malware are caught in the live query stream, before a signature exists.
03
Respond — contain without taking DNS down
Countermeasures adapt to what was found instead of dropping the service to stop the traffic, and the events go out to the tools the SOC already works in. Containment stays proportionate to the threat rather than becoming an outage of its own.
Outcome: threats are contained with block, quarantine or recovery countermeasures, and qualified events reach the SOC’s own tools for remediation.
04
Recover — keep answering under attack
A hybrid engine switch, DNSSEC and a high-throughput cache keep legitimate queries answered while volumetric traffic is absorbed. Availability is treated as part of the security control, because a resolver that stops answering has already caused the outage the attacker wanted.
Outcome: DNS keeps answering legitimate queries through volumetric floods, so applications stay reachable while the attack is absorbed.
Detection quality and false positives
Detection combines threat intelligence for known domains with behavioural analysis of the transactions themselves, so decisions rest on what the client is doing, not on a single list. Graduated countermeasures, including a patented quarantine mode, hold suspect traffic rather than blocking outright, which is how false positives are kept from becoming outages. EfficientIP does not publish a false-positive rate, and this page does not quote one.
Where it sits and how it behaves
A query leaves the client, reaches the resolver and comes back with an answer. Policy is applied on that path, and where it sits decides two things at once: what the user sees, and what the SOC receives.
[Diagram: DNS resolution path from client to resolver to answer, with the security policy enforcement point marked]
Deployment models
Every capability runs on SOLIDserver DNS appliances: hardware, virtual on VMware, Hyper-V, Nutanix, Proxmox or OpenStack, or cloud images on AWS, Azure and Google Cloud. DNS Guardian, DNS Firewall and Client Query Filtering are licensed as SOLIDserver capabilities; DNS Threat Pulse and the DNS Intelligence Center are cloud services added to them.
What happens when something breaks
Policy and detection run inside the resolver, so there is no separate inline device to fail. If a threat feed cannot be reached, the last received policy stays in force and resolution continues. Under volumetric attack, the hybrid engine and high-throughput cache keep answering; the DNS Blast appliance sustains up to 17 million queries per second.
What reaches the SIEM
Qualified security events are exported to Splunk, IBM QRadar, Kibana and Graylog, and shared with SOAR, NAC and threat intelligence platforms through APIs. Because the export is a SOLIDserver capability, DNS security events arrive in the same feed as DHCP and IPAM events.
| Query throughput | Scales with the SOLIDserver appliance model; the DNS Blast appliance sustains up to 17 million queries per second with filtering enabled. |
|---|---|
| Added latency per query | Policy evaluation and inspection happen inside the resolver, adding well under a millisecond per query on a sized appliance. Figure to be confirmed by EfficientIP. |
| Sizing guidance | Sized by peak queries per second and number of sites rather than user count. EfficientIP provides a sizing guide on request. |
Understand the threats
Definitions for the terms used on this page. Each one answers a single question and comes back here for what to do about it.
Data exfiltration
How data leaves a network inside DNS queries, and why the traffic looks legitimate to everything watching the connection.
DNS tunnelling
How a covert channel is built inside query and response payloads, and what a tunnelled session looks like in the query record.
Protective DNS
What the term covers, where it came from, and how it differs from filtering applied further along the connection.
DNS attacks
The attack types that target DNS itself, from cache poisoning to volumetric floods, and what each one is trying to achieve.
DNSSEC
What signing proves about an answer, what it does not protect against, and where it fits in a wider DNS security posture.
DNS filtering
How filtering decisions are made at the resolver, and what separates a policy engine from a blocklist.
How DNS-layer security compares with the controls you already have
Before anyone compares vendors, one question comes first: what does this cover that the firewall, the secure web gateway or the public DNS filtering service does not? The answer is where each control sits and what it can see from there.
| Criterion | Enterprise DNS security | Network firewall | Secure web gateway | Public DNS filtering service |
|---|---|---|---|---|
| Where in the session the decision is made | At the first query, before any connection exists | Once a connection is attempted, after resolution | Once web traffic reaches the proxy | At the query, on a resolver outside your network |
| Whether the query itself is inspected | Yes, including the transaction pattern behind it | No, it sees the resulting address and flow | No, it sees HTTP and HTTPS content | Yes, but only against the provider’s lists |
| A domain with no prior rule or reputation | Flagged by behaviour or as newly observed, and quarantined | Allowed; nothing to match | Allowed until URL categorisation catches up | Allowed until the provider lists it |
| Coverage for clients off the corporate network | Devices resolving through your resolvers, including over VPN | None once the device leaves the network | Yes, where the agent or PAC routes traffic | Yes, if the device is pointed at the service |
| Behaviour under volumetric attack | Absorbed on the resolver; DNS Blast sustains 17M queries per second | Firewall may saturate before DNS does | Not in the path for DNS floods | Provider’s problem, but your resolution depends on them |
One distinction is worth making plainly, because it comes up in most evaluations. A public cloud DNS filtering service and internal DNS infrastructure are not the same control. EfficientIP secures the resolvers the enterprise runs itself, which is what makes internal client behaviour visible in the first place.
Comparing EfficientIP against an incumbent DDI vendor is a different question with its own page: replacing an existing DDI vendor covers migration, cost and what changes operationally.
Evidence, not adjectives
A customer outcome
Replacing Infoblox and Microsoft DNS with EfficientIP has dramatically improved our network security and management. The unified platform simplifies operations, enhances security, and provides significant cost savings.
Giacomo Tizzanin IT Manager, Idroelettrica S.p.A
Infoblox and Microsoft DNS replaced by one platform, with security, operations and cost all reported as improved.
Analyst recognition
EfficientIP is recognised as a leader for DNS security in the 2026 GigaOm Radar, and its DNS security approach is covered in Forrester’s 2025 research on the category.
[Logo: analyst mark]
[Logo: analyst mark]
- 1,600+ Enterprise networks run on EfficientIP
- 98% Customer satisfaction
Find out what your DNS is already carrying
A datasheet describes our product. An exposure test tells you what is happening on your own resolvers, which is the more useful thing to have before a vendor conversation starts. Most teams find something worth investigating in the first week.
The test is free and read-only: nothing on your servers is changed. A short pre-briefing covers your authoritative and recursive DNS setup, EfficientIP’s toolkit then runs the exfiltration checks in about a minute, and a post-briefing walks through what was found and which countermeasures close it. No software is installed.
DNS security questions
What is DNS security?
DNS security is the practice of applying policy, inspection and resilience to the DNS service an organisation runs, so malicious names are never answered and the query record becomes usable evidence. It covers filtering, threat detection in the query stream and keeping resolution available under attack. The full definition goes further.
How is DNS security different from a firewall or a secure web gateway?
The point of enforcement, and what is visible from it. A firewall or gateway reads the connection after resolution has produced an address. A resolver reads the name itself, including names that have never been seen before and names that were generated minutes ago. Compare the control points above.
What is protective DNS?
Protective DNS describes a resolver that checks each query against threat intelligence and policy before answering, so a malicious name returns nothing usable. The term is common in government security guidance, and the control it describes is the protect stage of what this page covers. Read the definition.
Can DNS security detect data exfiltration?
Yes, because data leaving inside DNS queries has to pass through the resolver to work at all. Behavioural analysis of the query stream picks up the patterns that carry payloads, rather than waiting for the destination domain to appear on a list. An exposure test shows what your own traffic contains.
Does DNS security replace what we already run?
No. It closes a gap the rest of the stack was not built for. Firewalls, intrusion prevention and endpoint tools do not analyse the continuous stream of DNS queries, so tunnelling, generated domains and NXDOMAIN anomalies pass through them. DNS security adds that layer at the resolver every device already uses, and feeds what it finds into the SIEM and SOAR you already run.
How does DNS security help with NIS 2, DORA or GDPR?
All three expect you to protect essential services, detect incidents early and respond in a documented way. DNS security maps onto each: filtering and threat intelligence for protection, transaction inspection for early detection, and logged, exportable events with adaptive countermeasures for response and reporting. EfficientIP’s CISO Guide to NIST DNS Security covers the control mapping in detail; the legal interpretation for your sector remains yours.