DNS firewalls use your network’s core infrastructure to block, monitor, or redirect users attempting to access known malicious domains. Many go even deeper, modifying answers for particular clients to represent a NATed address. Some can even protect against data exfiltration through the DNS protocol itself by identifying DNS tunneling.
Standard firewalls tend to use complex, proprietary, and ultimately expensive signature detectors which don’t always catch DNS-based threats. By operating at the protocol layer, a DNS firewall protects a larger swath of the network. Deployment of a DNS firewall tends to be cheaper and easier, as it often works in concert with DDI management software.
As the number of DNS firewalls grows, we thought we’d put together a few thoughts on what security and network operation teams should consider when they’re looking for solutions. When your team is considering DNS firewall options, here are some questions you may want to ask.
What threat intelligence does this DNS firewall use?
Any filter or firewall is only as good as the data you plug into it. Threat feeds come in many forms, and it’s important to figure out which ones are going to offer the best value. Free, open-source threat feeds are available, but these generally aren’t “curated” to the same extent that a paid threat feed would be. You get what you pay for.
Some providers offer built-in threat feeds which 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 threat feed. What kind of information is it drawing from? How broad a customer base is it using to build out its threat feed, and what indicators is it using?
Other providers offer threat feed bundles (either exclusively or with a discounted rate) from major threat intelligence providers. When this is the case, access to the best intelligence will depend on the alliances and partnerships your DNS firewall 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, drawing intelligence from across the enterprise and pushing out actions to mitigate threats.
This is particularly true for DNS firewalls. DNS firewalls have access to the core DNS infrastructure which 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 which seamlessly operates with their SIEM or log management solution, providing that “single pane of glass” which makes correlation of threat data easy.
Where does this DNS firewall sit?
Placement of DNS firewalls is a critical question, but one which is often overlooked.
Most firewalls sit on the network boundary to protect against inbound threats 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 placement of a DNS firewall at the network boundary which deserves mentioning if and when you decide to go deeper.
Deployment of a DNS firewall 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. Ideally, DNS firewalls should integrate with your overall defense-in-depth strategy. If this is your goal (and it should be), the approach of having a DNS firewall at the network boundary will ultimately be insufficient.
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 device, it only sees the IP address of the “last hop” recursive DNS server. Some DNS firewall companies have tried to get around this with on-device agents which skirt the resolution process. That’s OK as far as it goes, but often ends up as a clunky, impractical solution in the end - you 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.
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 – these things can’t be detected by a DNS firewall focused on the outside internet.
The best way to protect internal DNS and gain visibility into the source IP of devices without the need for agents is to deploy your DNS firewall right at the endpoint or client level. With a DNS firewall there as the “first hop” DNS resolver, you can record the source IP and control traffic, whether it’s staying inside the network boundary or ultimately destined for the outside internet. As a bonus, you can also see how the DNS response data might indicate other threats to internal traffic.
How is this DNS firewall deployed?
Some DNS firewalls involve more boxes - either as part of an appliance-based DNS infrastructure, or as 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. That’s another appliance that you have to refresh (at significant additional cost) on a regular cycle of 2-3 years. That’s another appliance that you’re going to have to manually configure, update, or patch.
Life’s too short. 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. 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 significant load on the appliances. This prevents them from working at full capacity, which in turn requires more appliances to be deployed. Deploying a DNS firewall through a more lightweight solution like a VM-based service point is a better option in most cases.