Using DNS RPZ to Deliver DNS Firewall Services
- Updated on 07 Sep 2018
- 4 minutes to read
If you are a security company whose products include threat intelligence feeds, you can use DNS RPZ as a delivery channel to customers. Threats can be expressed as known-malicious IP addresses and subnets, known-malicious domain names, and known-malicious domain name servers. By feeding this threat information directly into your customer's local DNS resolvers you can transform these DNS servers into a distributed DNS firewall.
When your customer's DNS resolver is connected by a realtime subscription to your threat intelligence feed, you can protect the customer's end users from malicious network elements (including IP addresses and subnets, domain names, and name servers) immediately as you discover them. While it may take days or weeks to "take down" criminal and abusive infrastructure once reported, a distributed DNS firewall can respond instantly.
The open standard for DNS firewall policy control is called DNS RPZ, which stands for Response Policy Zone. This technology allows firewall rules to be expressed in a DNS zone format and then carried to subscribers as DNS data. A recursive DNS server which is capable of processing DNS RPZ will synchronize these DNS firewall rules using the same standard DNS tools and protocols used for secondary name service. The DNS policy information is then promoted to the DNS control plane inside the customer's DNS resolver, making that server into a DNS firewall.
Other distributed TCP/IP firewalls have been in the market for over a decade, and enterprise users are now comfortable importing real-time threat intelligence from their security vendors directly into their firewalls. This intelligence can take the form of known-malicious IP addresses or subnets, or of patterns which identify known-malicious email attachments or file downloads or web addresses (URLs). In some products it is also possible to block DNS packets based on the names or addresses they carry.
With DNS RPZ there is now a standard for distributed DNS firewalls including the basic feature level needed to trigger on either DNS names or DNS payloads, and an interchange format of the DNS firewall rule sets, and a synchronization method for distributing these rule sets to a broad set of subscribers in real time.
Let's look at some examples of what a DNS firewall can do.
Some known threats are based on an IP address or subnet (IP address range). For example your analysis may show that all addresses in a "class C" network are used by a criminal gang for "phishing" web servers. With a DNS firewall based on DNS RPZ you can express a firewall policy such as "if a DNS lookup would result in an address from this class C network, then answer instead with a no-such-domain indication." That simple rule would prevent any end users inside your customers' networks from being able to look up any domain name used in this phishing attack -- without having to know in advance what those names might be.
Other known threats are based on domain names. In this case your analysis may have determined that a certain domain name or set of domain names is being or will shortly be used for spamming, phishing, or other Internet-based attacks which all require working domain names. By adding name-triggered rules to your distributed DNS firewall you can protect your customer's end users from any attacks which require them to be able to look up any of these malicious names. The names can be wildcards (for example, *.evil.com) and these wildcards can have exceptions if some domains aren't as malicious as others (so, if *.evil.com is bad, then not.evil.com might be an exception.)
Alongside growth in electronic crime has come growth of electronic criminal expertise. Many criminal gangs now maintain their own extensive DNS infrastructure in order to support a large number of domain names and a diverse set of IP addressing resources. Analysis may show in many cases that the only truly fixed assets criminals have are their name servers, which are by nature slightly less mobile than other network assets. In such cases you can anchor your DNS firewall policies in the abusive name server names or name server addresses, and thus protect your customers' end users from threats where neither the domain name nor the IP address of that threat is known in advance.
For criminal assets which depend on DNS, this is like death from the sky.
Electronic criminals rely on the full resiliency of DNS just as the rest of digital society does. By targeting criminal assets at the DNS level we can deny these criminals the resilience they need. A distributed DNS firewall can leverage the high skills of a security company to protect a large number of end users. DNS RPZ, by being the first open and vendor-neutral distributed DNS firewall, can be an effective way to deliver your threat intelligence to customers.