Response Policy Zones, aka DNS Firewall

Motivation

Malware has grown to become a menacing force in enterprise networks, and it continues to grow more sophisticated to hide itself on host systems, operate stealthily to avoid detection and remediation, and contact external command and control (C&C) centers for new software and instructions. Such malware effectively transforms the host machine into a bot for remote use by the attacker, and such malware installed on multiple devices can be formed into a botnet with which the attacker may launch a variety of attacks from multiple endpoints.

Stealthy resilient malware is considered an advanced persistent threat (APT). The malware is advanced in its ability to adapt with software updates from the C&C center, persistent in the sense that it utilizes a variety of strategies to avoid detection and thus persist on the network, and a threat given the attack forms range from DDOS to data exfiltration. APTs often utilize DNS to locate the C&C center. After all, if the malware used a hard-coded IP address, the malware could be shut down by simply blocking the corresponding IP address once the malware has been detected.

Using DNS enables malware operators to modify their IP addresses to avoid detection. They often modify their domain name as well to likewise avoid shutdown, creating various forms of fast-flux networks using dynamically generated domain names. With the proliferation of mobile devices which employees bring into the office and connect to your network, users may bring infected devices physically into the confines of your network, you are susceptible to internal attacks instigated by malware unwittingly installed on user devices.

And malware can also be installed on residential or non-user devices which may be less protected from Internet-based attacks. The 2016 DDOS attack on Brian Krebs’ security blog leveraging the Mirai malware installed on Internet of Things (IoT) devices highlights this vulnerability (US Computer Emergency Response Team, 2016). This attack infiltrated over 380,000 IoT devices with the Mirai malware and launched a DDOS attack exceeding 620 Gbps. The botnet was formed by leveraging default user names and passwords installed on IoT devices such as surveillance cameras and home routers.

By analyzing your DNS query data, you may be able to identify the presence of malware within your network before your anti-virus software has remedied a block for it. While relying exclusively on DNS query data to detect malware is by no means recommended, DNS query analytics can serve as valuable input to your overall malware detection “eco-system” and mitigation strategy. Data from hosts, routers, firewalls, intrusion detection systems, and DNS can all help identify suspicious and malicious activity.

How a DNS firewall Helps

A DNS firewall enables you to configure DNS to modify answers to certain queries or queries answered from particular servers. While configuring DNS to “lie” was initially frowned upon by Internet purists, unfortunately the nature of the Internet today necessitates consideration of passing on query answers that can lead to data exfiltration and/or manipulation of a given host or others for nefarious purposes. Other forms of query answer manipulation can also be configured with recursive servers, such as DNS64 for IPv4 reachability from IPv6 networks and NXDOMAIN redirection to other destiations, e.g., search pages for monetization.

DNS firewall technology provides the ability to block certain DNS queries to known bad actor domains. It also provides for the modification of DNS responses to clients to redirect them to an internal “walled garden” for example. DNS firewall technology enables enterprises and service providers to reduce the probability of malware proliferation within their networks. It also enables service providers to offer incremental revenue features such as parental controls and related domain blocking, while enabling compliance with domain or end user blocks imposed by law enforcement.

Response Policy Zone (RPZ) is the DNS implementation term which provides the DNS firewall functionality. An RPZ is a special zone that defines the triggers and associated policies for queries or answers matching each trigger. For example, known malware domains or authoritative DNS servers of ill-repute may be encoded as triggers for which response policies may be defined. Such RPZ trigger and policy information can be updated periodically using in-house bad domain information and/or an RPZ data provider via signed zone transfers. RPZ feeds can be generated and managed internally and/or by leveraging external RPZ data providers such as Farsight Security, Diamondback Networks, DissectCyber, SpamHaus, SURBL and ThreatStop.

Response policy zones, like normal zones, contain resource records, the alphabet of DNS. RPZ resource records encode query and response triggers and corresponding policies for response disposition. Triggers can be defined as:

• a given queried domain name (or within a domain branch)
• query answer IP address (or block)
• authoritative name server IP address or domain name.
• client IP address

Thus throughout the resolution process for a particular query, the recursive DNS server can logically filter at multiple points along the way, then enact the corresponding policy action prior to sending the response to the client. Based on one of these triggers, policies can be defined to respond to the query with either:

• NXDOMAIN – indicates an answer for the queried name was not found
• NODATA – signified by a NOERROR response with no query answers (a zero “answer count”); this indicates a queried name was valid but no data for the queried type was found
• pass-through - no alteration of the answer
• drop - provide no response to the query
• tcp-only - respond with the truncated (TC) bit set in the DNS header to stimulate another query over TCP
• local policy such as directing the querier to portal or walled garden web page indicating an invalid query or otherwise communicating with the user.

In addition to DNS firewall configuration, these caching servers may also be configured to perform DNSSEC validation to enable validation of signed resource record sets. This requires configuration with the current Internet root zone public key (DNSKEY KSK record data). Caching servers can also be configured to automatically maintain this trust anchor public key as the root zone rolls.

Other recursive security settings should also be configured to provide maximum availability and reliability to the DNS recursive service. Such settings include setting ACLs to constrain from what IP networks or addresses recursive queries may be made for example, configuring denial of service rate limiting if available, restricting the number of outstanding queries per client and limiting the query depth to minimize the chasing of bogus queries. These settings are examples and your name server implementation may offer different and/or additional security features as well.

RPZ Policy Declarations

Within each response policy zone, you can define individual triggers and corresponding response policy. As with every zone, each RPZ must contain an SOA record and an NS record, e.g.,

Triggers are defined within the owner field of the resource record while the corresponding policy comprises the Rdata portion. Triggers as described above are encoded within resource records as follows:

• QNAME - the owner field matches a given queried domain name (or within a domain branch using a wildcard (*))
• RPZ-IP suffix - query answer IP address (or block)
• RPZ-NSIP suffix - authoritative name server IP address
• RPZ-NSDNAME - authoritative name server domain name.
• RPZ-CLIENT-IP - client IP address

Policies are encoded as follows.

• CNAME . - NXDOMAIN – indicates an answer for the queried name was not found
• CNAME *. - NODATA – signified by a NOERROR response with no query answers (a zero “answer count”); this indicates a queried name was valid but no data for the queried type was found
• CNAME rpz-passthru. - pass-through the answer to the querier
• CNAME rpz-drop. - provide no response to the query
• CNAME rpz-tcp-only. - respond with the truncated (TC) bit set in the DNS header to stimulate another query over TCP
• Normal resolution - local policy such as directing the querier via a CNAME, A or AAAA resource record to a corresponding hostname or IP addres defined in the Rdata. This policy is hepful for steering the querier to a portal or walled garden web page.

The following examples illustrate response policy zone resource records.

DNS Firewall Configuration on BIND

A DNS firewall is configured in BIND using the response-policy option. This option currently enables definition of up to thirty-two response policy zones, each of which may comprise sets of individual resource records that enumerate response policies. Note that processing of RPZ triggers matches the first match. Individual zones are canonically ordered when loaded, so be aware that the order of resource records in the zone may not correspond to that of the loaded zone. But you can control zone ordering since zones are processed in the order listed. You may want to list any pass-thru (e.g., allow-listed) triggers in a separate zone which is listed among the first set of RPZs in the response-policy statement.

BIND 9.11 Response Policy Declaration

The BIND response-policy statement enables declaration of these zone files as RPZs. This first section of the response-policy stanza, within the curly brackets, defines each RPZ and enables policy overrides per declared zone (e.g., disable all policies defined in the file for troubleshooting for example, respond to all triggers with NODATA, etc.). These per-zone parameters include the following.

• log - log queries/responses that map to a trigger defined in this zone. Logging must also be configured for the rpz logging category.
• max-policy-ttl – this statement enables setting of the time to live (TTL) of the response resource record. The TTL dictates how long the client should cache this response. Once the cache expires, the client will issue a query once again should the client request this information. This enables rapid refreshing of policies if desired. This policy may be applied to an individual zone or all response policy zones.
• policy - enables application of a blanket policy to all triggers defined in the zone.
• recursive-only – this policy indicates PRZ processing shall only apply to recursive queries (default); this policy may be applied to an individual zone or all response policy zones.

The second part of the response-policy declaration enables policy settings across all RPZs including:

• break-dnssec – by default, RPZ is not applied to queries where DNSSEC validation has been requested. Given that DNSSEC authenticates the publisher and data integrity of the DNS response, any change to the response per RPZ policy would by definition destroy the message integrity and invalidate the DNSSEC signature. Setting this parameter to “yes” instructs the server to perform RPZ processing even on DNSSEC queries, permitting the server to “break DNSSEC.”
• max-policy-ttl – this statement enables setting of the time to live (TTL) of the response resource record. The TTL dictates how long the client should cache this response. Once the cache expires, the client will issue a query once again should the client request this information. This enables rapid refreshing of policies if desired. This policy may be applied to an individual zone or all response policy zones.
• min-ns-dots – This parameter applies globally and stipulates the number of “dots” in the queried domain name that must exist to apply RPZ processing. A value of “1”, the default, would apply to example.com for example
• nsip-wait-recurse – Normally, the recursive server performs full recursion to ascertain the query answer prior to seeking a response policy action. Setting this parameter to “no” instructs the server to access its cache for the Qname and, if it exists, the corresponding answering DNS server IP address. If the IP address is defined as a RPZ-NSIP trigger, apply the corresponding policy immediately, bypassing full recursion.
• qname-wait-recurse – Normally, the recursive server performs full recursion to ascertain the query answer prior to seeking a response policy action. Setting this parameter to “no” configures the server not to await recursion, since it receives the Qname with the query from the client, and to apply any defined response policy for the Qname immediately.
• recursive-only – this policy indicates PRZ processing shall only apply to recursive queries; this policy may be applied to an individual zone or all response policy zones.

BIND 9.16 Response Policy Declaration

The BIND response-policy statement enables declaration of these zone files as RPZs. This first section of the response-policy stanza, within the curly brackets, defines each RPZ and enables policy overrides per declared zone (e.g., disable all policies defined in the file for troubleshooting for example, respond to all triggers with NODATA, etc.). These per-zone parameters include the following.

• add-soa - dictates whether the response policy zone's SOA record is added for tracking of zone changes; the default is yes.
• log - log queries/responses that map to a trigger defined in this zone. Logging must also be configured for the rpz logging category.
• max-policy-ttl – this statement enables setting of the time to live (TTL) of the response resource record. The TTL dictates how long the client should cache this response. Once the cache expires, the client will issue a query once again should the client request this information. This enables rapid refreshing of policies if desired. This policy may be applied to an individual zone or all response policy zones.
• min-update-interval – this clause sets an minimum time interval between successive updates to this response policy zone. If an update is made, e.g., via IXFR less that this value after the last update, the new update won't be applied until this value has elapsed.
• policy - enables application of a blanket policy to all triggers defined in the zone.
• nsip-enable – this clause enables the overriding of responding name server IP address triggers in the zone file. Setting nsip-enable no disables NSIP triggers.
• nsdname-enable – this clause enables the overriding of responding name server name triggers in the zone file. Setting nsdname-enable no disables NSDNAME triggers in the file.
• recursive-only – this policy indicates PRZ processing shall only apply to recursive queries; this policy may be applied to an individual zone or all response policy zones.

The second part of the response-policy declaration enables policy settings across all RPZs including:

• add-soa - dictates whether the response policy zone's SOA record is added for tracking of zone changes; the default is yes.
• break-dnssec – by default, RPZ is not applied to queries where DNSSEC validation has been requested. Given that DNSSEC authenticates the publisher and data integrity of the DNS response, any change to the response per RPZ policy would by definition destroy the message integrity and invalidate the DNSSEC signature. Setting this parameter to “yes” instructs the server to perform RPZ processing even on DNSSEC queries, permitting the server to “break DNSSEC.”
• max-policy-ttl – this statement enables setting of the time to live (TTL) of the response resource record. The TTL dictates how long the client should cache this response. Once the cache expires, the client will issue a query once again should the client request this information. This enables rapid refreshing of policies if desired. This policy may be applied to an individual zone or all response policy zones.
• min-update-interval – this clause sets an minimum time interval between successive RPZ updates. If an update is made, e.g., via IXFR less that this value after the last update, the new update won't be applied until this value has elapsed.
• min-ns-dots – This parameter applies globally and stipulates the number of “dots” in the queried domain name that must exist to apply RPZ processing. A value of “1”, the default, would apply to example.com for example
• nsip-wait-recurse – Normally, the recursive server performs full recursion to ascertain the query answer prior to seeking a response policy action. Setting this parameter to “no” instructs the server to access its cache for the Qname and, if it exists, the corresponding answering DNS server IP address. If the IP address is defined as a RPZ-NSIP trigger, apply the corresponding policy immediately, bypassing full recursion.
• qname-wait-recurse – Normally, the recursive server performs full recursion to ascertain the query answer prior to seeking a response policy action. Setting this parameter to “no” configures the server not to await recursion, since it receives the Qname with the query from the client, and to apply any defined response policy for the Qname immediately.
• recursive-only – this policy indicates PRZ processing shall only apply to recursive queries; this policy may be applied to an individual zone or all response policy zones.
• nsip-enable – this clause enables the overriding of responding name server IP address triggers for all RPZs. Setting nsip-enable no disables NSIP triggers.
• nsdname-enable – this clause enables the overriding of responding name server name triggers for all RPZs. Setting nsdname-enable no disables NSDNAME triggers.
• dnsrps-enable – enables or disables the DNS Response Policy Service (RPS) API, which enables use of an external response policy provider as an alternative to response policy zones.
• dnsrps-options { unspecified text } – configures the DNS Response Policy Service (RPS) provider library, librpz; the unspecified text is passed to the library, concatenated with settings derived from this response policy statement.