A DNS firewall checks every domain name lookup against threat intelligence and blocks, redirects or sinkholes answers for malicious destinations before a connection opens. It is cheap, fast to deploy and catches a lot of commodity abuse. It does not replace endpoint or network controls, and it can be bypassed.
How does a DNS firewall work?
Almost every connection starts with a lookup: the device asks a resolver for the address behind a name. A DNS firewall sits in that path. If the requested name matches an indicator in its feed, such as a known command-and-control domain or a phishing site, the resolver refuses to give the real answer.
CISA describes this model in its Protective DNS Resolver service for US federal agencies. Queries pass through the resolver for active filtering. When a request matches a threat intelligence indicator, the service blocks, redirects or sinkholes the response and sends an alert to the originating agency and to CISA. CISA notes the service sits upstream from agency networks and does not interfere with internal DNS design, and that traffic from mobile, roaming and cloud assets goes to it directly.
Those three outcomes are worth separating. Blocking returns a failure. Redirecting sends the user to a warning page. Sinkholing points the name at an address you control so you can see which device tried to reach it. Sinkhole logs are often the most useful output, because they name infected machines.
What can it catch?
Three common cases:
- A user clicks a phishing link on a newly flagged domain.
- Malware on a laptop tries to call its command server by name.
- A script pulls a payload from a domain that threat feeds already list.
What can it miss?
A DNS firewall only sees names. It cannot help when malware connects to a raw IP address, when a domain is new and not yet in any feed, or when abuse happens on a legitimate service such as a file-sharing site. It also loses visibility when software resolves names on its own. Some browsers and apps can send lookups over encrypted channels to a resolver you did not choose, which skips your filter entirely.
Use the control for what it is: a first, low-friction layer that removes the easy cases and generates early warning.
What does a rollout look like?
A constructed example: a 120-person company points its office DHCP at a filtering resolver in alert-only mode for two weeks. The log shows an old accounting plugin calling an expired domain every few minutes, and one contractor laptop querying a domain tied to adware. Neither would have shown up in firewall rules. After cleaning both, the team switches to blocking for the malware and phishing categories, and keeps alert-only for broader categories like newly registered domains until it has seen the false positive rate.
Roaming laptops need their own plan. If the filter only applies on the office network, a laptop on home Wi-Fi is unprotected. Choose a client agent, a managed profile or an encrypted DNS setting that points to your resolver off-network.
How to check or apply this
- Decide where lookups happen today: office resolvers, cloud virtual networks, laptops, containers.
- Start in alert-only mode and read the logs for two weeks before blocking anything.
- Block malware, phishing and command-and-control categories first.
- Block outbound DNS to any resolver except yours on the firewall, so devices cannot sidestep the filter. Allow exceptions deliberately.
- Decide how roaming devices and cloud workloads send lookups to the same policy.
- Send resolver logs to your log store. Alert on repeated lookups of sinkholed names, since each one points at a device to investigate.
- Test with a known-safe test domain from your provider, and set a path for staff to report false positives.
Quick check
Is a DNS firewall the same as a network firewall?
No. A network firewall filters connections by address, port and protocol. A DNS firewall filters name lookups before the connection starts. They work well together.
Can malware avoid a DNS firewall?
Yes. It can connect by IP address, use a domain nobody has flagged yet, or send lookups through an encrypted channel to a resolver outside your control.
Sources
Last reviewed: 18 October 2026.
