Support Central: KB#3451: Configuring CLI commands for Automated Mitigation of Phantom Domain Attack

[#1]

Problem Summary

Configuring CLI commands for Automated Mitigation of Phantom domain attacks

Customer Environment

Infoblox DNS appliances operating with recursive DNS services

Versions

NIOS 6.12.1 and higher

Resolution

Customers that are being hit with Phantom domain attacks can now automatically mitigate these attacks by using several newly-available CLI commands in NIOS 6.12.1.

Increase the recursive client quota

Depending on the hardware type that is used for handling recursive DNS queries, you can increase the recursive client quota from the GUI. Navigate to Data Management --> DNS --> Members --> Select member --> Edit Member DNS properties --> Queries --> Advanced --> Enable. Change the default value for Limit number of recursive clients to the appropriate value for your hardware type.

For example: 20,000 recursive clients can be set on an IB-1552-A or an IB-1852-A; 40,000 recursive clients can be set on an IB-4010 or an IB-4030.

Set recursion query timeout to 10 seconds.

The BIND statement resolver_query_timeout is by default set to 30 seconds, the CLI command set recursion_query_timeout is the equivalent for this BIND statement and allows us to decrease this value.

The CLI command set recursion_query_timeout command sets the amount of time the resolver will spend attempting to resolve a recursive query before failing.

To help mitigate the Phantom domain attack use the CLI command, set recursion_query_timeout 10.

Fetches per zone setting

Use the set fetches_per_zone CLI command to configure the maximum number of recursive queries the DNS server sends to a domain. If the number of recursive queries exceeds the configured value, the server blocks new queries to that domain and returns a SERVFAIL response to the client. The default value for max_queries is 200.

set fetches_per_zone <max_queries>

set fetches_per_zone on (switch fetches per zone on with the default value or with the last configured value)

set fetches_per_zone off (switch fetches per zone off)

The following information is logged into the syslog when this setting is enabled:

2014-10-29T10:20:06+00:00 daemon infoblox named [25390]: info too many simultaneous fetches for foo.com (allowed 200, forced 2, spilled 123)

Fetches per server setting

Use the set fetches_per_server CLI command to configure the maximum number of concurrent recursive queries that the appliance sends to a single upstream DNS server. Queries above the limit will be blocked and may result in a SERVFAIL response to the client. When you enable this option, the appliance dynamically adjusts the concurrent query limit for a specific server based on the average timeout ratio (ATR). The default value for fetches is 500. The default value for frequency is 200.

set fetches_per_server <fetches> <frequency>

set fetches_per_server on (switches fetches per server on with the default values or the last configured values)

set fetches_per_server off (switches fetches per server off)

The following information is logged into the syslog when this setting is enabled:

2014-10-29T10:20:06+00:00 daemon infoblox named[25390]: info adb: quota 10.0.0.2 (100/150): atr .10, quota increased to 200
2014-10-29T10:20:06+00:00 daemon infoblox named[25390]: info adb: quota 10.0.0.2 (200/200): atr .80, quota decreased to 150

Hold Down timer

NOTE:  The "set hold down" setting is now deprecated in favor of "fetches-per-server" and "fetches-per-zone".

Use the set holddown CLI command to ignore non-responsive DNS servers for a specified time interval. You can use this command to specify the threshold value (the number of consecutive timeouts before holding down a server). When the number of consecutive attempts to contact a non-responsive server exceeds the threshold value, the appliance stops sending queries to the non-responsive servers. The default values are 60 for time, 5 for threshold, and 1000 is the min_timeout. 

set holddown <time> <treshold> <min_timeout>

set holddown on (switches hold down timer on with default values or last configured values)

set holddown off (switches hold down timer off)

The following information is logged into the syslog when this setting is enabled:

2014-10-17 07:00:07.322Z [admin]: Called set_holddown: Args holddown_time="60",holddown_threshold="5", holddown_timeout="1000"

2014-10-29T07:04:53+00:00 daemon infoblox named[26986]: info adb: clearing holddown for 10.0.0.2
2014-10-29T07:04:53+00:00 daemon infoblox named[26986]: info adb: timeout: setting 10 second holddown for 10.0.0.2 after 5 timeouts
2014-10-29T07:04:53+00:00 daemon infoblox named[26986]: info adb: timeout: resetting 10 second holddown for 10.0.0.2 after 1 timeouts

More information about the above CLI commands is available in the 6.12 CLI Guide.

Customers that are operating DNS Firewall (RPZ) should also disable the NSDNAME and NSIP rules for RPZ zones. The NSDNAME and NSIP rules are enabled for RPZ zones by default.

When you enable RPZ on internal DNS servers and if there are forward-mapping zones that are not reachable from external networks, NSDNAME and NSIP validation is not necessary. In this case, you can disable NSDNAME and NSIP rules to reduce delays in responses. When you disable these rules for RPZ zones, the appliance bypasses NSDNAME and NSIP validation for the queries and significantly improves performance.

Note that this setting disables both NSDNAME and NSIP rules at the same time for both internal and external RPZ zones. This setting only affects the lookup process. The zone data remains unchanged. NSDNAME and NSIP records will still be available in RPZ zones during zone transfers (AXFR and IXFR). If you disable NSDNAME and NSIP rules for RPZ zones at the Grid level, all members inherit this setting. You can override this setting for each member.

Be aware that security is reduced when you disable NSDNAME and NSIP rules for RPZ zones on those members which may send recursive queries to external servers. Accordingly, Infoblox does not recommend disabling these rules for RPZ zones on those members that respond with data from external servers. Neverthess, for the best results in mitigating the Phantom Domain attack, these rules should be disabled.

For additional information, see the NIOS Admininstrator Guide for DNS Firewall - Managing RPZ rules, the NIOS 6.12 Release Notes for the new feature, and the NIOS 6.12 CLI Guide.

Reference documentation can be found on the Infoblox support portal in the Tech Docssection.