DNS Firewall Threat Feeds are delivered in the industry standard Response Policy Zones (RPZ) format. These zones are called ‘policy’ for a good reason, i.e., they allow you to choose and implement the protection policies that you want. When choosing DNS Firewall Threat Feeds its key to ensure you pick the right ones based on the relevant level of protection your business requires, otherwise you could be making things more tricky than they need to be.

Bacon and eggs anyone?

Have you been to a buffet breakfast recently? Did you overeat? Be honest…. A little or a lot? It is so tempting to fill the plate with fruit and yogurt, followed by bacon & eggs, finishing up with a couple of pancakes before finally squeezing in a pastry.

When we’ve paid for something we want to get our monies worth. It’s tempting to do the same with DNS Firewall Threat Feeds. The subscription has been paid so it makes sense to utilize all the feeds at their highest level of security, right? Surely the more intelligence data you utilize, the safer your network and the happier your end-users will be?

Sadly this is not the case. You need to be strategic in your choice of feeds based on the following:

Scales showing Risk your business can afford to take V commercial requirements of your business

Risk your business can afford to take V commercial requirements of your business

Take a look at the tales of two businesses below to understand what we mean:

The network carrier
An internet service provider (ISP), let’s call it KommuneeK8, uses DNS Firewall Threat Feeds. They have chosen to utilize every piece of data available in their response policy zones, i.e., all standard feeds and all hacked feeds.

KommuneeK8 has a domestic customer called Susie. Susie has an expectation (and rightly so) that she will always be able to access her favorite independent shopping website called Spinning Tunes, to purchase rare vinyl records.

Meanwhile, in another corner of planet earth, the shared hosting environment which Spinning Tunes’ website is hosted on has been compromised and is being used as part of a botnet command & control (C&C). As a result, the internet protocol (IP) address, on which Spinning Tunes’ domain resides has been listed on Deteque’s “BotnetCC IPS Hacked ” feed.

The consequences of the listing are that Susie is unable to access the Spinning Tune’s website and has subsequently missed out on purchasing the rare Beatles Abbey Road 1987 UK LP pressed on red vinyl. Susie is not happy. So she calls her ISP to ‘loudly’ express her dissatisfaction at the fact.

While KommuneeK8 had the best intentions of providing a safe browsing environment for their end-user, in this case, the IP listing of a shared resource is going to cause multiple false positives. Ultimately the ISP implemented security policies and chose DNS Firewall Threat Feeds that were too restrictive for their commercial needs.

Now let’s visit a healthcare provider…

The Healthcare provider

Frank works in the finance team of a large healthcare provider. He also wants to visit Spinning Tunes website, and like Susie can’t access it because his company is running DNS Firewall Threat Feeds.

Frank gets pretty frustrated and calls his IT help desk who remind Frank that he is using company property, on a company network, in company time to make a personal purchase! They advise him that healthcare has more breaches than any other sector, and the highest costs associated with stolen data records, therefore they have chosen to follow a low-risk strategy when it comes to cybersecurity.

In this scenario, when you weigh up the risk to the company against service to the end-user, it’s perfectly acceptable for the healthcare provider to be utilizing the feeds that are likely to block all domains & IPs that have any potential risk associated with them. The healthcare provider’s IT security team understand that more sites than perhaps necessary may be blocked, but consider this to be a better outcome than their network being compromised.

Choosing the right DNS Firewall Threat Feeds for your business

As a security or network professional, you have the unenviable task of balancing business needs against the expectations of your end users. As this hypothetical example has shown, different businesses will have different needs and approaches.

In fact, different users within the same business present different risk profiles and may warrant different policies. Be clear about your business’ security profile. Get appropriate sign-off. Then communicate the selected approach to customer-facing support teams and, more importantly, end users.

Trial DNS Firewall for Free

DNS Firewall – A beginner’s guide

Discover DNS Firewall Threat Feeds

With the ever increasing demands on IT, security and networking teams, tools that reduce workloads, which don’t cost the earth, are always welcome.  One such tool is DNS Firewall. For those not familiar with how DNS Firewall works, and the benefits it provides, read on…

An introduction to DNS Firewall

At its most basic level, similar to traditional firewalls, DNS Firewall blocks/redirects end-users from accessing malicious sites.  The main difference between the two is that DNS Firewall is applied at a different layer and phase, namely threat intelligence data feeds are applied to the domain name system (DNS).  This circumvents the loss of visibility that is making traditional firewalls less effective due to the significant increases in end to end encrypted traffic.

But why should you use it?

In addition to protecting your users against identity theft, installation of malware and data exfiltration, there are other reasons to use this type of firewall as part of your multi-layered security, including:

Educating your end users: Following an attempt to connect to a bad domain you can enlighten your end-user as to the danger they have just avoided e.g. potentially connecting to a phishing site.  This can either be done via a landing page which they are redirected to, or by reaching out to them directly; turning a bad decision into a positive teaching opportunity.

Freeing up your busy team: Utilizing this kind of firewall automatically mitigates some of the serious issues that may arise on your network as a result of it being compromised.  This provides your teams with additional time to focus on resolving other pressing network and security issues.

Gaining insight to be proactive: It provides you with more visibility into compromised users or clients on your network.  This enables you to take immediate action without the time lag of either being notified by a third party, or discovering the issue at a later date, be that days, weeks or months after the attack.

It’s easy to apply & simple to maintain: Once this firewall has been applied to the DNS all the clients on your network, including IoT devices, are protected from accessing malicious sites.  This minimizes deployment resources.  Meanwhile the data feeds, against which potential connections are checked, are continuously update.  This removes the need for upgrades and updates.

Brand protection: For ‘trusted’ brands online security breaches can have a huge impact on business.  One only has to look to British Airways in the UK and their significant data breach to understand the consequences.  It is vital to have multiple layers of security to keep company networks and users ‘safe’.

Lower cyber risk insurance costs:  Insurance (and its associated costs) probably don’t fall under your department’s responsibilities or budget.  However, it’s highly likely that someone in your organization will be pleased to discover that implementing DNS Firewall can reduce your cyber risk insurance costs.

How can DNS Firewall be implemented?

There are three ways to implement DNS Firewall. It is worth noting that all three use ‘threat intelligence data feeds’ to identify bad domains, however there are differing ways in how you can access/utilize these feeds:

Data and synchronisingOn-premises open source software:  Threat intelligence data feeds are transferred via AXFR/IXFR to your DNS resolver as ‘zone’ files. Originally, DNS Firewall was designed to be an open and translatable standard, with it’s initial home being BIND.  Now other DNS servers such as PowerDNS, Knot, and Unbound also provide support for using DNS Firewall threat feeds.

On-premises appliance: An internal solution/application, located within your network, working as a management system for your DNS’s security infrastructure which utilizes threat intelligence data feeds. Depending on the supplier you may, or may not, have the flexibility to choose your preferred data feed supplier.

Cloud with data flowing in and outCloud: Service providers with their own DNS resolvers which are protected by DNS Firewall with threat intelligence data feeds, and are accessed, like a managed service, by customers.

How DNS Firewall works

Picture of how DNS firewall work

Let’s take a deeper dive into how DNS Firewall works:

Standard DNS Resolvers: When an end-user attempts to go to a website/domain, the resolver will query a root server, then a top-level domain server, and finally the server of the site, which will complete the resolution of the request by the end-user.  The client’s request to access the site will take place regardless of whether the site is malicious or not.

DNS Resolver with DNS Firewall: During the resolution process “zones”, which consist of sets of threat intelligence data, are queried.  The requested domain is analyzed for potential security risks against the data sets, and if a match is returned the request is blocked or redirected.

Take a look at the examples below to see what end-users may potentially see if they tried to connect to a phishing site in each of the following situations:

No DNS Firewall: phishing site accessed


text saying "This site can't be reached".

DNS Firewall enabled: phishing site blocked


advisory notice that user attempted to access a phishing site

DNS Firewall enabled: phishing site blocked and advice provided for user

Where the DNS Firewall is enabled the end-user who has attempted to access the phishing site has been prevented from doing so, and consequently protected from the potential harm that could lead to.  Moreover, because the mitigation has occurred at the DNS level there has been no need for the end-user to install an additional program or update software on their workstation.

What next?

DNS Firewall has the potential to free up teams to accomplish other tasks and build a secure proactive, not reactive, network experience for everyone within your organization.

Now you know how DNS Firewall works it’s time to look at what considerations you need to be making when implementing it.

10 Questions for your DNS Firewall Provider

Discover DNS Firewall Threat Feeds

Trial DNS Firewall for Free

If you are looking to protect your users, customers and IoT devices from connecting to malicious sites via a domain name system (DNS) firewall you have multiple choices.   Here are key questions to ask your potential DNS Firewall provider (and yourself!) to ensure you make the right choice for your business’s needs.

Ways of deployment

Let’s start with the basics; currently, there are 3 different ways to deploy DNS Firewall:

On-premises open source software: Threat intelligence data feeds from a third party accessed through your DNS infrastructure.

On-premises solution/appliance:  This is located within your network, working as a management system for your DNS’s security infrastructure, which uses threat intelligence data feeds.

Cloud:  A service which is external to your network, where a third party manages your DNS requests.

1. How is DNS Firewall set-up and configured?

Be certain to look at this implementation holistically and consider the ‘big picture’.  Ensure you choose a solution that meets your needs, and not simply one that is the fastest to install. Key elements to consider are:

  • Quality of threat data 
  • Pricing
  • Control 
  • Flexibility
  • Transparency
  • Support
  • Testing period¹

On-premises open source software: This is a more technical implementation because you configure the threat intelligence data feeds directly into your DNS.  Here it is vital to understand the support that will be given by the service provider during the implementation.

On-premises appliance:  A more in-depth implementation is usually involved.  You will be required to make direct changes to your DNS.  You will also be required to choose DNS threat intelligence data feeds to use in your Response Policy Zones (RPZ).

Cloud service: Typically you will only be required to make minimal changes to your DNS set-up.  This will simply involve pointing your recursive resolver to a different IP address, through which you will run your DNS resolution.

2. How much does it cost?

Cost is always a key factor when looking at purchasing new services or hardware. Consider if you have (or need to make a business case for) capital budget, or are wanting a solution which can fit into your operational budget, on a subscription basis.

On-premises open source software: Prices in this category should be amongst the lowest, as you are transferring threat intelligence feeds into your own DNS resolver, and won’t have any hardware costs to pay.

On-premises appliance:  Prices should be lower per user than using a cloud service, given that you are installing something onto your own network. However, establish if any additional fees need to be paid to use ancillary services on these appliances.  

Cloud service: This is generally more expensive per user because of the provider’s infrastructure costs, in addition to the cost of distributing their threat intelligence throughout their network.  The set-up is relatively easy (see #1), however, this is a service you share with multiple users, therefore you lose flexibility and control, and you may end up paying for data feeds that you don’t require. 

Remember that some on-premises solutions and direct DNS data feeds both have a more complex set-up (see #1).  Having said this, you will be rewarded for your efforts by having a large amount of control, both in terms of the different data feeds you utilize, and instant access to your redirect/block information.

3. Can I tailor your threat intelligence data feeds to my needs?  

Organizations need to have the flexibility to assess the amount of risk they want to take.  Question if you are able to pick the data feeds (i.e. the threat intelligence that’s being used to block/redirect on your network) that provide the right level of security for your business requirements.  

Some industries e.g. financial and healthcare services require additional levels of security so they may want to have a strong focus on policy-based data feeds.  On the other hand, if you need to be less risk adverse e.g. those managing end-user networks, you don’t want to have to pay for feeds that you don’t use.

Furthermore, there are organizations who require multiple levels of security across different areas of their network, for example, academic institutions will require a different level of protection for students compared to that of the staff.

4. What is the quality and breadth of your threat feeds? 

Cybercriminals use a range of techniques to extort information, and ultimately money, from their victims.  Your DNS Firewall is only as good as the threat data it receives to block connections.  These feeds need to be diverse and well researched, protecting you against as many malicious domains as possible. Furthermore your threat data needs to have a low rate of false positives, particularly across non-policy focused feeds. 

Whether you go down the route of choosing an appliance or decide to configure your own DNS, you will need to source a supplier for the data feeds.  Ensure it is someone who is well established in providing threat intelligence and draws data from a wide range of independent sources. 

5. How do I resolve issues with false positives?

If a business critical domain is being redirected/blocked you need to be certain that you can make an exception to the policy decision of your DNS Firewall, so your business can continue to operate without disruption. 

On-premises open source software & appliance: Is there the flexibility to add the domain to a private whitelist to allow you instant access to the blocked domain? 

Cloud services:  Check service level agreements (SLAs) for response and action times in relation to whitelisting and/or removing blocked domains that are business critical for you.  See to it that these are acceptable to your business needs.

6. How often is your data updated?

Timely threat intelligence is fundamental to countering cybercriminal activities across your network.  According to a Ponemon Institute Survey, 37 percent of attackers quit if they can’t yield value after a period of 10 hours.  

With this in mind, ensure that the data protecting you is delivered as continuously as possible: An update that occurs only every hour could fail to protect from the potential damage malware can do upon its initial release.

7. Can infected devices be easily traced on my network?

Whilst you can control most of what happens on your network, you can’t control what happens within your customer environment(s) or when employee devices are taken offsite, for example, working at a client’s offices, or from home. 

Botnet Command & Controller (Botnet C&C) listings increased by a huge 32% in 2017 (read the full Botnet Threat Report).  Given the upsurge in threats from this area, it is vital to be able to trace any infected devices on your network, to enable you to take rapid and effective action.  

Establish with your DNS firewall provider how attempted access to malicious sources can be detected using DNS firewalls on your network.  Remember to check if there is any need to install additional agents/software, which would lead to additional costs and complexity.  

8. How and when will I be notified of issues on my network?

Having ‘control’ is fundamental to most IT security teams.  The sooner a threat is flagged, the sooner relevant remediation can take place, be that for your customer if you are an ISP or Hosting provider, or your employee if you are an enterprise business.

On-premises open source software & appliance: Determine if you have the ability to set up your own logs, so you are immediately aware the moment a block/rewrite occurs, or receive notification if there is an infected client on your network.  This will enable you to take action without delay.

Cloud service: Establish if reports specific to your network are pushed out in real-time.  Consider the impact on your business if you had to wait to receive information on a redirect or a botnet infected machine.

9. How stable is your service? 

On-premises open source software: Ascertain that any provider of threat feeds has multiple access points for their data.  This will ensure that even if there is an issue with some of their servers you will continue to receive service from one of their alternative locations.

On-premises appliance: If you are using an appliance you need to be sure that your DNS will still function, even without the DNS firewall, if the solution fails.

Cloud service: Be certain of contingency plans in regards to service failure,  as this could potentially mean that you could lose all access to DNS connections, crippling your business. Gain a clear understanding of their SLAs, and if they’ve been met historically.  

10. Can I write my own redirect pages?

Why is this important?  Well, because it is an opportunity to transform something negative i.e. a cybercrime into a teachable moment for the end-user.  

A generic message only informs that a block/redirect has occurred:

The requested web page from has been blocked 

However, a carefully crafted landing page which provides the end-user with ‘why’ they have been blocked and ‘how’ they can protect themselves in the future will positively contribute to increasing the ongoing security of your network.   For further information and examples of ‘teachable moment’ landing pages, click here.


With such a huge growth in the DNS Firewall market over the past few years there are plenty of options to choose from.  Simply (!) take the time to understand your business needs and carefully research what option meets them.

DNS Firewall – A beginner’s guide

Discover DNS Firewall Threat Feeds

Trial DNS Firewall for Free

¹We would recommend a 30 day testing period.

UPDATED 30th JULY 2018

No-one wants their devices hijacked for crypto mining so Deteque, a division of Spamhaus, has added a new layer of security with the introduction a ‘Cryptominer’ zone as part of its DNS Firewall Threat Feeds.

bit coin with pick axe and text saying Crypto miner protection added to DNS Firewall feed

Deteques new crypto miner zone added to DNS firewall feed

Deteque researchers are constantly tracking the networks of crypto miners who use adverts, often on legitimate websites, to run JavaScript and other code that can drain processing power via the browser for crypto mining without any actual malware being installed on a user’s machine.

With the new zone included in an organization’s DNS management, users will still get access to the websites they want to visit, but the adverts used for crypto mining are blocked as part of the DNS resolution process. This way malicious adverts are blocked before a connection is made a so there is no need for dedicated software or tools on an individual’s device.

The Cryptominer Zone is accessible as part of the Diverse category of our DNS Firewall response policy zone data feeds. Find out more.

DNS Firewall Threat Data from Deteque is currently used by ISPs, corporations and public institutions world-wide. Find out more.

Further reading on crypto jacking:

Protection against fraud and phishing is now boosted with Zero Reputation Domains (ZRD) threat intelligence from Deteque, a division of Spamhaus.

We have added a ZRD zone to Deteque’s DNS Firewall Threat Feeds, which can be used as a check in an organization’s DNS management to block malicious and low reputation domains. With the new ZRD data feed, network security managers can block access to newly-registered domains which are often associated with fraud or phishing attempts.

Cyber criminals immediately use newly registered domains for websites, hoping that users will fall victim before a domain has been analyzed for its reputation, as opposed to legitimate organizations who will rarely activate a domain and start using it as soon as it has been registered.

The ZRD zone automatically adds newly-registered and previously dormant domains to a blocklist for 24 hours. Once the domain is older than 24 hours it will be removed from this zone, or if the domain is deemed malicious by other tests it will be added into another zone.

DNS Firewall Threat Feeds from Deteque are currently used by ISPs, corporations and public institutions world-wide. Find out more and start your 30 day free trial today

Existing RPZ subscribers can reach out to their Spamhaus partner to enquire about adding ZRD to their subscription.