How to choose the right DNS firewall for your network

A DNS firewall uses your network’s core infrastructure in real-time to block, monitor, or redirect users attempting to access known malicious domains.

However, there are numerous DNS firewall solutions available today. How do you pick the right one for your network? For starters, asking the right questions can help.

This post will first briefly cover the benefits of a DNS firewall. Then, it will delve into the questions that security and network teams should consider when choosing a DNS firewall: what threat intelligence it uses, how it integrates with the rest of the network, and how it’s deployed.

Finally, it will touch on the critical question of where a DNS firewall sits and why BlueCat’s client-facing approach is best.

Benefits of a DNS firewall

Standard firewalls tend to use complex, proprietary, and expensive signature detectors that don’t always catch DNS-based malware and threats. These firewalls detect and block all kinds of other general threats and prevent malware from entering networks.

Meanwhile, by operating at the protocol layer, a DNS firewall works to protect a larger part of the threat landscape. Deployment of a DNS firewall tends to be cheaper and easier, as it often works in concert with a DDI management platform. (DNS, DHCP, and IP address management are together known as DDI.)

Often, a DNS firewall blocks malicious activity by going even deeper. Some can modify answers for particular devices to represent an address that has undergone network address translation (NAT). Others can protect against data exfiltration through the DNS protocol itself by identifying DNS tunneling.

What threat intelligence does this DNS firewall use?

Any filter or firewall is only as good as the data you put in it. Threat feeds come in many forms, and it’s important to figure out which ones offer the best value. Free, open-source threat feeds of malicious sites are available, but these generally aren’t curated to the same extent as paid threat feeds. You get what you pay for.

Some providers offer built-in threat feeds that they maintain themselves. In these cases, you’ll want to gauge how the company is getting its threat data, as well as its long-term commitment to maintaining a proprietary feed.

What kind of information is it drawing from? How broad a customer base is it using to build out its threat feed? What indicators is it using?

Other providers offer threat feed bundles from major threat intelligence providers. When this is the case, access to the best intelligence will depend on the alliances and partnerships your provider chooses to go with.

Maybe a certain threat feed provider has the best intelligence for your particular market vertical. Or maybe you already have a subscription to a particular feed that you’d like to roll into a DNS firewall solution. It pays to ask.

How does this DNS firewall integrate with the rest of my network?

No firewall is an island. Your network security systems should actively work with the management tools you use every day. They should draw intelligence from across the enterprise and push out actions to mitigate threats.

This is particularly true for DNS firewalls. They have access to the core DNS infrastructure that powers the millions of DNS queries your network produces on a daily basis. If your DNS firewall integrates with network management resources like Active Directory, Cisco ISE, and other sources of network data, you’ll be in a strong position to implement a consistent security posture across the enterprise.

Security teams will also want a DNS firewall that seamlessly operates with their security information and event management (SIEM) platform or log management solution. Doing so provides a single pane of glass to easily correlate threat data.

How is this DNS firewall deployed?

Some DNS firewalls involve more boxes. It could be part of an appliance-based DNS service or infrastructure. Or it could be a separate appliance that you add on top of whatever DNS you’re already using.

That’s another appliance that you have to fit into your data center. It’s yet another appliance that you have to refresh (at a significant additional cost) on a regular cycle. And it’s another appliance that you have to manually configure, update, or patch.

In the age of SaaS solutions delivered from the cloud, there’s no reason that you should have to deal with another appliance just to get a DNS firewall in place. And there’s no reason that you should have to upload configurations and patches on your own.

All of this stuff should just happen in the background. The latest versions should just be pushed out directly to you without any action on your side.

Even if you don’t get an appliance-based solution, it’s important to pay attention to the deployment model. If your DNS firewall is an add-on to existing recursive DNS systems, it can add a significant load on the appliances. This prevents them from working at full capacity, which in turn requires deploying more appliances.

Deploying a DNS firewall through a more lightweight solution like a virtual machine-based service point is a better option in most cases.

Where does this DNS firewall sit?

The placement of DNS firewalls is a critical question, but one that is often overlooked.

Most firewalls sit on the network boundary to protect against inbound DNS attacks from the internet. That’s a good place to start, but there’s a lot more you can do. There’s also an inherent technical limitation involved with the placement of a DNS firewall at the network boundary.

Deploying it on the network boundary will prevent the spread of malicious traffic, but it cannot help you find patient zero when that malicious traffic originates from inside the network.

Ultimately, it’s a network architecture problem. If a DNS firewall at the network boundary wants to look back into the stack to find the source IP of a compromised device, it only sees the IP address of the “last hop” recursive DNS server.

On-device agents as a workaround

Some DNS firewall companies have tried to get around this with on-device agents that skirt the resolution process. That’s OK, but it often ends up as a clunky, impractical solution in the end. Admins have to deploy and maintain all of those agents. And not all devices (IoT sensors, for example) even have the capacity to handle them in the first place.

Furthermore, the other thing you miss with a DNS firewall placed on the network boundary is all of your internal DNS traffic. That means that about 60% of all the queries bouncing around your network will go unmonitored. Malicious insider activity, lateral movement by advanced persistent threats—a DNS firewall focused on the outside internet can’t detect and block these things.

Deploying a client-facing firewall is best

Ultimately, the best way to provide full DNS security and gain visibility into the source IP of compromised devices is to deploy your DNS firewall at the client level.

Learn more about a client-facing DNS firewall in this quick video:

With BlueCat Edge, a DNS firewall is there as the “first hop” DNS resolver. With it, you can record the source IP and control traffic. It’s doesn’t matter whether it’s staying inside the network boundary or ultimately destined for the outside internet.

As a bonus, you can also see how DNS response data might indicate other threats to internal traffic. Learn more about BlueCat’s network security solutions that sit at the network edge.