DNS Firewall: block malicious domains and data exfiltration at the DNS layer
EfficientIP DNS Firewall filters malicious domains, blocks data exfiltration and enforces policy where every session starts, before a connection is ever made. It runs on the DNS servers your network already depends on, so there is no new inline device and no agent on the endpoint.
Security teams set the policy. Network operations keep the resolution path they already run.
Rated five stars for real-time DNS security in the GigaOm Radar for DDI.
[Image: hero graphic]
The threats that never reach a firewall rule
A DNS firewall is a security control that inspects DNS queries as they are resolved and refuses to answer for domains that are known-malicious, newly generated, or outside policy. It acts on the DNS servers a network already runs, before any connection is made, rather than on the traffic a perimeter firewall sees afterwards.
Almost every attack starts with a name lookup. Malware calls home. A compromised host resolves a domain that was generated seconds earlier. A tunnelling tool moves data out inside query payloads that a perimeter device reads as ordinary traffic.
The controls most enterprises already own inspect the connection after resolution has handed it an address. That is late, and none of them can see the query that produced the address. Enforcement at the resolver moves the decision to the point where intent is still visible and the connection has not been made.
Fewer hosts reach infrastructure they should never have reached, and the security team keeps the query record to prove it. That record is something a SOC can work with, rather than another blocked-connection count, and it is where data exfiltration shows up while it is still happening. This is the layer the rest of the DNS security solution builds on.
Where the decision happens in the resolution path
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 what the user sees and what the SOC receives.
- 1 Client sends the query
- 2 Resolver evaluates it against policy
- 3 Answer is returned, or the query is blocked and logged
[Diagram: DNS resolution path with the policy enforcement point marked]
Policy sources and feeds
Policy is built from response policy zones. EfficientIP DNS Threat Pulse supplies the primary feed, covering phishing, malware and ransomware, botnet command-and-control, compromised sites and newly observed domains, and any third-party RPZ feed can be loaded beside it. Your own allow and block lists sit alongside the feeds as local zones and take precedence over them.
What a blocked query returns
By default a blocked query receives NXDOMAIN, so the client behaves as if the domain does not exist. Policy can instead return a sinkhole address or redirect the client to an internal landing page that explains the block. Every hit is logged with the client address, the requested domain, the policy zone that matched and the action taken.
What it detects and what it stops
Domains already known to be malicious
Queries for domains listed in the threat feeds or your own block lists are stopped or redirected before any connection is made. The operator sees the requesting client, the domain and the matched policy in the RPZ report.
Data leaving inside DNS queries
Known tunnelling and exfiltration domains are blocked from the feed. Behaviour that has no domain reputation yet is the job of DNS Guardian, which inspects the transactions themselves; where both run, Guardian’s detections feed the same log the operator already reads.
Generated domains and low-signal behaviour
The newly observed domains category in DNS Threat Pulse lets you block or monitor domains first seen in the last hours, before any reputation exists. The operator sees them as their own category in the report, so a policy can start in monitor mode and tighten later.
Policy that differs by client or group
Policy zones are applied per DNS server or view, so a site, a network segment or a client group can carry a different policy. For per-user and per-application decisions, DNS Client Query Filtering adds identity-aware policy on the same resolver. Reports break down filtered domains and the clients requesting them.
Detection quality and false positives
Filtering acts only on domains that match a policy zone, so ordinary traffic resolves unchanged. Allow lists override every feed, and a policy can run in log-only mode before it is set to block. The vendor does not publish a false-positive rate, and this page does not quote one.
How it deploys and how it behaves under load
DNS Firewall runs inside the DNS service you already operate, so the deployment question is about policy distribution and failure behaviour rather than about a new device in the path.
| Deployment models | Embedded in SOLIDserver DNS software appliances: hardware, virtual (VMware, Hyper-V, Nutanix, Proxmox, OpenStack) or cloud images on AWS, Azure and Google Cloud. No separate node is added. |
|---|---|
| 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 happens 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. |
| If policy evaluation fails | Policy zones are held locally on each resolver. If a feed transfer fails, the last received policy stays in force and resolution continues; nothing fails open or closed at the network level. |
| Multi-site and multivendor estates | One change to the policy is pushed to every DNS server in the architecture in a single operation, on SOLIDserver appliances and on Linux BIND servers managed by SOLIDserver alike. |
Automation, integrations and the API
Everything the console does, the REST API does. Policy, feeds and exceptions are all addressable, so DNS enforcement can live in the same pipeline as the rest of your network configuration.
Send events where the SOC already works
Filtering events are exported through the SOLIDserver logging engine to Splunk, IBM QRadar, Kibana and Graylog, alongside the DHCP and IPAM events the platform already sends. Each event carries the client, the domain, the matched policy zone and the action taken, and the built-in RPZ report shows filtered domains and the clients requesting them without leaving the console.
Automate policy the way you automate everything else
Policy zones and allow or block lists are managed through the SOLIDserver REST API, so Ansible, Terraform, Chef, Puppet or a SOAR playbook can drive them the same way as the rest of the platform. Start from a working example: getting started with the SOLIDserver REST APIs is the practical walkthrough, and the SOLIDserver API for IT automation covers the wider surface.
DNS-layer enforcement compared with the controls you already run
Before anyone compares vendors, one question comes first: why does the firewall, the secure web gateway or the endpoint agent already in place not cover this? The answer is where each control sits and what it can see from there.
| Criterion | DNS layer | Network firewall | Secure web gateway | Endpoint agent |
|---|---|---|---|---|
| Where the control sits | On the resolver every device already uses | At the network edge, inline | In the web proxy path, usually cloud-hosted | On each managed device |
| What it sees at that point | Every domain lookup from every device, before a connection exists | IP addresses, ports and inspected flows once a connection starts | HTTP and HTTPS web traffic routed through it | Process and file activity on that device only |
| Coverage off the corporate network | Devices that resolve through the corporate resolver, including over VPN | None once the device leaves the network | Yes, when the agent or PAC routes traffic to it | Yes, wherever the device goes |
| A domain seen for the first time | Flagged or blocked as a newly observed domain | Allowed; no reputation to match | Depends on URL categorisation, usually allowed | Allowed unless a payload later triggers detection |
The vendor-by-vendor comparison lives on one page: replacing Infoblox.
In production
A European retail bank with 4,000 branch and office endpoints was seeing malware call-backs slip past its perimeter firewall. After enabling DNS Firewall on its existing SOLIDserver resolvers, the security team blocked command-and-control lookups at the first query and cut malware-related incident tickets by roughly a third in the first quarter.
GigaOm awarded EfficientIP five stars for real-time DNS security in its Radar for DDI, and EMA named the company a Value Leader in the 2025 EMA Radar for DDI.
Take the detail with you
The datasheet covers deployment models, sizing and the full capability list. It opens on its own page, so you can send it to a colleague who has not read this one.
[Image: datasheet cover]
DNS Firewall datasheet
DNS Firewall: Protecting and Defending Against Malware (PDF)
Terms used on this page
Common questions
What is a DNS firewall?
A DNS firewall applies policy to DNS queries at the resolver, so a name that resolves to something malicious is never answered. The decision happens before the connection is attempted, which is what separates it from filtering that runs once an address has already been handed back. What is DNS filtering? covers the longer definition.
How is this different from the filtering my firewall already does?
The point of enforcement, and what is visible from there. A firewall reads the connection after resolution has produced an address. A resolver reads the query itself, including names that have never been seen before. Compare the control points for the full breakdown.
Does it work for devices that are off the corporate network?
DNS Firewall protects any device that resolves through your SOLIDserver resolvers, which includes remote users on VPN or with corporate DNS pushed to the device. A device using a public resolver off the network is not covered; that gap is where endpoint or cloud DNS filtering complements it.
Do we need SOLIDserver DDI to run DNS Firewall?
Yes. DNS Firewall comes embedded in SOLIDserver DNS software appliances and is licensed as a SOLIDserver capability, not as a separate device. It is a separate product from DNS Guardian; the two run together on the same resolver and are often bought together.
What happens to a query that gets blocked?
By default the client gets NXDOMAIN, so the application reports that the site cannot be found. If you configure a redirect instead, the browser lands on an internal page explaining the block. Either way the event is logged with the client, the domain and the policy that matched.
How do we see what it stopped?
Reporting and event export are covered in Automation, integrations and the API on this page.
See what your DNS traffic is already carrying
Most teams find something in the first week. Request a data exfiltration test against your own resolvers and an engineer who runs these deployments will walk you through what it found.