Response Rate Limiting (RRL)

 RRL, or Response Rate Limiting, is a security feature implemented in DNS servers to mitigate the impact of Distributed Denial of Service (DDoS) attacks, particularly DNS amplification attacks. It works by limiting the rate at which DNS responses are sent from a server to a particular client or set of clients.

When a DNS server receives an unusually high volume of requests, possibly as part of an attack, RRL kicks in to restrict the number of responses sent back to any given requester over a specified period. This helps to prevent the server from being used as a tool in amplification attacks, where large numbers of responses are sent to a victim's network, overwhelming its bandwidth. It is implemented in DDI Central using the rate-limit DNS option.

Configuring RRL in DDI Central

To configure it select DNS-> Config-> DNS Options

On the DNS options page, click on the Options drop down box to search for rate-limit option.

The rate-limit option appears with all its attributes. Fill in the values for each attribute and click Save.

Here are explanations for various attributes of the rate-limit option:

1. all-per-second: Limits the total number of all responses (regardless of type) per second.
2. errors-per-second: Limits the number of error responses (like SERVFAIL) per second.
3. ipv4-prefix-length and ipv6-prefix-length: Define the subnet mask length for aggregating IPv4 and IPv6 addresses. This dictates how broadly the rate limiting is applied across a range of IP addresses.
   For example, ipv4-prefix-length of 24 means that the server will apply rate limits to all addresses in each /24 subnet as a group. Therefore, all requests originating from the 192.168.1.0/24 subnet, for instance, would be collectively subject to the specified rate limit.
4. exempt-clients: Specifies clients (usually by IP address or subnet) that are exempt from rate limiting. This is often used for trusted networks.
5. log-only: When enabled, BIND just logs the rate-limited responses without actually enforcing the limits. This is useful for testing and monitoring the potential impact of rate limiting without actually dropping or truncating responses. 
6. max-table-size: The maximum number of entries in the rate-limiting table.This table keeps an account of the clients and the rate of responses sent to them. A larger table can track more clients but requires more memory. Example: Setting max-table-size to 2000 limits the tracking table to 2000 client entries creating DNS query floods.
   Note: The max-table-size parameter is crucial because it controls how many unique clients can be tracked simultaneously for rate limiting. If the number of clients exceeds this limit, older entries may be removed or new clients mighht not be tracked, depending on the implementation. 
    
7. min-table-size: The minimum size of the rate-limiting table. Setting a minimum table size ensures that the DNS servers can handle a baseline number of clients for rate limiting. This is particularly important in environments where the number of DNS query flooding clients varies but never drops below a certain threshold.
   Note: By specifying a minimum table size, admins can ensure that there is always enough capacity to handle a predictable amount of traffic, even during peak times. This helps in better managing server resources and avoiding performance degradation. Also, it prevents the overhead associated with dynammically adjusting the table size too frequently, ensuring smoother operations. Example: Setting the min-table-size to a value of 500, ensures the rate-limit tracking table can handle at least 500 entries.
8. nodata-per-second: Limits the number of responses per second that result in NODATA (no error but no data).It controls the rate of NODATA responses to avaoid potential abuse.
9. nxdomains-per-second: Limits the number of NXDOMAIN (non-existent domain) responses per second.Helps to mitigate the impact of NXDOMAIN flooding attacks.
10. qps-scale: A factor by which to scale the queries per second calculation. It can be used to adjust the sensitivity of rate limiting.
11. referrals-per-second: Limits the number of DNS referral responses per second.
12. responses-per-second: Limits the number of identical responses per second from a single IP address or subnet.
13. slip: Defines the behavior when a rate limit is exceeded. Typically, every nth response will be truncated.
    The slip setting determines how often the DNS server will send a truncated response instead of dropping the response entirely when rate limiting is in effect. A truncated response is a response that tells the querying client that it should retry the request over TCP instead of UDP. Since TCP connections require more resources to establish, attackers are less likely to use them, making DDoS attacks less effective.

Here’s a breakdown of the slip option:

1. Value 0: The server will drop all responses that exceed the rate limit.
2. Value 1: The server will send a truncated response for every request that exceeds the rate limit.
3. Values 2 and higher: The server will send truncated responses for one out of every 'slip' number of requests that exceed the rate limit. For example, if the slip value is set to 2, then the server will send a truncated response for every second request that exceeds the limit.

       14. window: The time period, in seconds, over which BIND calculates the rate of identical responses for rate limiting.

Example

15. rate-limit {
16.    responses-per-second 10;
17.    window 5;
18.    ipv4-prefix-length 24;
19.    ipv6-prefix-length 48;
20.    slip 2;
21.    nxdomains-per-second 5;
22.    nodata-per-second 5;
23.    errors-per-second 2;
24.    all-per-second 20;
25.    max-table-size 100000;
26.    exempt-clients { 192.168.0.0/24; };
27.    log-only yes;
28. };
29.  

From the above configuration example, DDI Central will limit identical DNS responses to 10 per second over a 5-seconds window. If the limit is exceeded, DDI Central will start sending truncated responses every second request (split=2). The local network (192.168.1.0/24) is exempt from these limits, and the log-only setting means the limits will be logged but not enforced, which is helpful for initial testing.