What Exactly is a DNS Firewall?

When you think of an Internet firewall, you likely think of a gateway device which examines IP packets flowing through it and which selectively blocks or redirects those packets meeting certain criteria. Such criteria may include filtering parameters such as IP addresses or ports such that when an IP packet under inspection matches such parameter settings, the packet is blocked or otherwise handled according to policy settings. A DNS firewall performs similar examination and policy handling functions for DNS queries to prevent unwelcome DNS and subsequent data traffic.

Another common assumption associated with Internet firewalls is that they are deployed on the perimeter of a network with the intention of protecting the network from attacks originating external to the network. DNS firewalls however protect the network against attacks that originate within the network. Why worry about internal attacks if morale is sky high and IP firewalls are seemingly impervious? With the proliferation of smart phones and "bring your own device" (BYOD) initiatives intentionally or unintentionally established, it's quite possible that devices physically leaving the domain of a perfectly firewalled network may elsewhere become infected with malware when operated on less secure networks such at as the coffee house wifi or at home.

Certain forms of malware infiltrate a device as a remote agent or "bot" which, along with several other similarly infected devices, forms a "botnet" where an attacker can command several bots to perform attacks such as distributed denial of service attacks. A bot on an infected device will typically attempt to contact the attacker's command and control (C&C) center to receive its marching orders, and the means of contacting the C&C starts with a DNS lookup. The primary goal of a DNS firewall is to identify such C&C contact attempts, to block such attempts and to identify the infected device.

The leading DNS server reference implementation, BIND from the Internet Systems Consortium (ISC) supports the establishment of DNS firewall policies via its response policy zones (RPZ) feature. RPZ enables a DNS administrator to define policies in standard DNS resource record format to enable filtering of DNS queries. Filtering triggers can be defined based on the queried name (QNAME), resolved IP address (IP address within A or AAAA query response), resolving name server IP (NSIP) as resolved within a response to the A or AAAA query for an NS RRSet, and resolving name server name (NSDNAME) as resolved within an NS RRSet. Thus throughout the resolution process for a particular query, the recursive DNS server can filter at multiple points along the way, then enact the corresponding policy action. Such action can be defined as responding with NXDOMAIN, NODATA, pass through, or inclusion of predefined response data, such as directing the session to a walled garden.

The beauty of this technique is in defining policies as resource records within a zone or zones which enables DNS administrators to create their own policies and/or to subscribe to a provider or providers of malicious domain (filtering) information, which can simply zone transfer such domain information to the corresponding recursive DNS servers. Updates of this zone information of course should be secured via the use of standard BIND ACLs as well as transaction signatures (TSIG) to sign incremental or full zone updates.

BT Diamond IP's IP address management products support configuration of DNS firewall functions via its web user interface for our Sapphire appliances as well as stock ISC BIND servers you may already operate. We also partner with Internet Identity as a provider of bad domain information which can be easily configured with our systems though customers are free to implement their own policies using our systems or use other or additional bad domain providers. Feel free to contact me to learn more.