Product Documentation

Mitigating DNS DDoS attacks

Apr 26, 2017

DNS servers are one of the most critical components of a network, and they must be defended against attacks. One of the most basic types of DNS attacks is the DDoS attack. Attacks of this type are on the rise and can be extremely destructive.  To mitigate DDoS attacks, you can flush negative records, restrict the time to live (TTL) of negative records, preserve NetScaler memory by limiting the memory consumed by the DNS cache, retain DNS records in the cache, and enable DNS cache bypass. You can also limit DNS queries to a single packet and thereby prevent Slowloris attacks.

Flushing Negative Records

A DNS attack fills the cache with negative records (NXDOMAIN and NODATA). As a result, responses to legitimate requests are not cached, so new requests are sent to a back-end server for DNS resolution. Responses are therefore delayed.

You can now flush the negative DNS records from the NetScaler appliance's DNS cache.

To flush negative cache records by using the NetScaler command line

At the command prompt, type:

flush dns proxyrecords -type (dnsRecordType | negRecType) NXDOMAIN | NODATA

Example

flush dns proxyrecords –negRecType NODATA

To flush of negative cache records by using the NetScaler GUI

  1. Navigate to Configuration > Traffic Management > DNS > Records.
  2. In the details pane, click Flush Proxy Records.
  3. In the Flush Type box, select Negative Records.
  4. In the Negative Records Type box, select either NXDOMAIN or NODATA.

Protection Against Random Subdomain and NXDOMAIN Attacks

To prevent random subdomain and NXDOMAIN attacks, you can restrict the DNS cache memory, and you can adjust the TTL values for negative records.

To  limit the amount of memory consumed by the DNS cache, you  can specify the maximum cache size (in MB), and also the cache size (in MB) for storing negative responses. When either limit is reached, no more entries are added to the cache. Also, syslog messages are logged and, if you have configured SNMP traps, SNMP traps are generated. If these limits are not set, caching continues until the system memory is exhausted.

A higher TTL value for negative records can result in storing records that are not valuable for a long period of time. A lower TTL value results in sending more requests to the back-end server.

The TTL of the negative record  is set to a value that can be lesser of the TTL value or the ”Expires” value of the SOA record.

Note:

  • This limitation is added per packet engine. For example, if the maxCacheSize is set to 5 MB and the appliance has 3 packet engines, the total cache size is 15 MB.
  • The cache size for the negative records must be less than or equal to the maximum cache size.
  • If you reduce the DNS cache memory limit to a value lower than the amount of data already cached, the cache size remains above the limit until data ages out (exceeds its TTL0 or is flushed (flush dns proxyrecords command, or Flush Proxy Records in the NetScaler GUI).
  • To configure SNMP traps, see Configuring the NetScaler to Generate SNMP Traps.

To use the NetScaler command line to limit the memory consumed by the DNS Cache

At the command prompt, type:

set dns parameter -maxCacheSize <MBytes> -maxNegativeCacheSize <MBytes>

Example

set dns parameter - maxCacheSize 100 -maxNegativeCacheSize 25

To use the NetScaler GUI to limit the memory consumed by the DNS Cache

Navigate to Configuration > Traffic Management > DNS, click Change DNS Settings, and set the following parameters:

  • Max Cache Size in MB
  • Max Negative Cache Size in MB

To restrict TTL of negative records by using the NetScaler command line

At the command prompt, type:

set dns parameter -maxnegcacheTTL <secs>

Example

set dns parameter -maxnegcacheTTL 360

To restrict TTL of negative records by using the NetScaler GUI

  1. Navigate to Configuration > Traffic Management > DNS.
  2. Click Change DNS Settings and set the Max Negative Cache TTL in sec parameter.

Retaining DNS Records in the Cache

An attack can flood the DNS cache with entries that are not valuable but can cause flushing of the already cached legitimate records to make room for the new entries. To prevent attacks from filling the cache with invalid data, you can retain the legitimate records even after they exceed their TTL values.

If you enable the cacheNoExpire parameter, the records currently in the cache are retained until you disable the parameter.

Note:

  • This option can be used only when the maximum cache size is specified (maxCacheSize parameter).
  • If maxnegcacheTTL is configured and cacheNoExpire is enabled, cacheNoExpire takes priority.

To retain DNS records in the cache by using the NetScaler command line

At the command prompt, type:

set dns parameter -cacheNoExpire ( ENABLED | DISABLED)

Example

set dns parameter -cacheNoExpire ENABLED

To retain DNS records in the cache by using the NetScaler GUI

  1. Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
  2. Select Cache No Expire.

Enabling DNS Cache Bypass

For greater visibility and control of DNS requests arriving at the NetScaler appliance, you can set the cacheHitBypass parameter to forward all requests to the back-end servers and allow cache to be built but not used. After the cache is built, you can disable the parameter so that requests are served from the cache.

To enable DNS cache bypass by using the NetScaler command line

At the command prompt, type:

set dns parameter -cacheHitBypass ( ENABLED | DISABLED )

Example

set dns parameter -cacheHitBypass ENABLED

To enable DNS cache bypass by using the NetScaler GUI

  1. Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
  2. Select Cache Hit Bypass.    

Preventing the Slowloris Attack

A DNS query spanning multiple packets presents the potential threat of a Slowloris attack. The NetScaler appliance can silently drop DNS queries that are split into multiple packets.

You can set the splitPktQueryProcessing parameter to ALLOW or DROP a DNS query if the query is split into multiple packets.

Note: This is applicable only for DNS TCP.

To limit the DNS queries to a single packet by using the NetScaler command line

At the command prompt, type:

set dns parameter -splitPktQueryProcessing ( ALLOW | DROP )

Example

set dns parameter -splitPktQueryProcessing DROP

To limit DNS queries to a single packet by using the NetScaler GUI

  1. Navigate to Configuration > Traffic Management > DNS and click Change DNS Settings.
  2. In the Split Packet Query Processing box, choose ALLOW or DROP.

Collecting Statistics of the DNS Responses Served from the Cache

You can collect statistics of the DNS responses served from cache and use these statistics to create a threshold beyond which additional DNS traffic is dropped, and enforce this threshold with a bandwidth based policy. Previously, bandwidth calculation for a DNS load balancing virtual server was not accurate, because the number of cache hits was not reported.

In proxy mode, the statistics for Request bytes, Response bytes, Total Packets rcvd, and Total Packets sent statistics are continuously updated. Previously, these statistics were not always updated, particularly for a DNS load balancing virtual server.

Proxy mode also now enables you to determine the number of DNS responses served from the cache. To help collect these statistics, the following options have been added to the stat lb vserver <DNSvirtualServerName> command:

  • Requests – Total number of requests received by the DNS or DNS_TCP vserver. Includes the requests forwarded to the back end and the requests answered from the cache.
  • Vserver hits –Total number of requests forwarded to the back end. The total number of cache hits is the difference between Requests and Vserver hits.
  • Responses – Total number of responses sent by this vserver. For example, if a DNS LB virtual server received 5 DNS requests, forwarded 3 of them to the back end, and served 2 of them from the cache, the corresponding value of each of these statistics would be as follows:
    • Vserver hits: 3
    • Requests: 5
    • Responses: 5