Response Rate Limiting in Windows DNS Server
RRL, or Response Rate Limiting, tries to extenuate the DNS amplification attacks. In a DNS amplification attack, the attackers forge the IP address of the victim network and send a lot of queries to the DNS servers. The traditional DNS server responds back to all the queries it receives and as a result the victim network gets a huge amount of unwanted DNS responses . The attackers can orchestrate this attack to involve multiple DNS servers all of which start sending unsolicited responses to the victim network, which chokes down on the high volume of inbound packets, slows down and eventually collapses.
Apart from this, DNS brings an element of amplification (more so with DNSSEC). The attacker can send small queries that can result in large responses. Certain DNS servers that act as "Open Resolvers" on internet are specifically vulnerable to facilitate this kind of attack, as they can be easily made to respond with highly amplified response. Even purely authoritative servers respond with amplified referral responses, or amplified responses for 'ANY' queries. This makes it easier for the attacker to orchestrate a reflection attack with smaller number of queries.
The internet has seen many such attacks in near past, most famous of which was the Spamhaus DDoS attack, where multiple DNS servers were tricked into sending a gigantic amount of traffic to Spamhaus servers, thereby choking it down.
In Windows Server 2016, the DNS server will provide an option to enable Response Rate Limiting. Response Rate Limiting intends to prevent the abuse of Windows DNS servers for orchestrating an amplification attack. Although there is no way to identify the legitimacy of a single query on UDP, but preventive actions can be taken if the DNS servers can identify potentially malicious queries. As DNS clients and resolvers are expected to cache the responses, if a lot of queries originate from single source asking for similar names within a specified time window, they can be flagged as potentially malicious. With RRL enabled, Windows DNS servers will first identify the potentially malicious queries and then take preventive actions. The obvious prevention is not to respond. The other option is to respond back with truncation, so that the clients who are genuine revert back on TCP*, where the protocol ensures legitimacy of client via its three-way handshake. Overall, with RRL enabled, the Windows DNS server will put an upper limit to the number of similar responses that it will send to clients from the same subnet.
* The TCP session setup has its own overhead.
By default RRL, is disabled on Windows DNS Server. To enable it the admin has to input
Set-DNSServerRRL
This enables RRL on the DNS server with default settings (See more at Set-DnsServerResponseRateLimiting ) . The admin can also alter the settings of Response Rate Limiting as per the deployment needs. These settings are as under:
| Name | Description |
| ResponsesPerSec | Specifies the maximum number of times that the server sends a client the same response within a one-second interval. The default value is 5. |
| ErrorsPerSec | Specifies the maximum number of times that the server can send an error response to a client within a one-second interval. The error responses include: REFUSED, FORMERR and SERVFAIL. The default value is 5. |
| WindowInSec | Specifies the period (in seconds) over which rates are measured and averaged for RRL. RRL is applied if queries from same subnet, resulting in same response, occur more frequently than expected in a specified time window. The default value is 5. |
| IPv4PrefixLength | Specifies the IPv4 prefix length, which indicates the size of the subnet in which the incoming queries are grouped. The server applies RRL if queries from same IPv4 subnet resulting in the same response occur more frequently than expected in a specified time window. The default value of this parameter is 24. |
| IPv6PrefixLength | Specifies the IPv6 prefix length, which indicates the size of the IPv6 subnet in which the incoming queries are grouped. The server applies RRL if queries from same IPv6 subnet resulting in the same response occur more frequently than expected in a specified time window. The default value of this parameter is 56. |
| LeakRate | Specifies the rate at which the server responds to dropped queries. For queries that meet criteria to be dropped due to RRL, the DNS server still responds once per LeakRate queries. For example, if LeakRate is 3, the server responds to one in every 3 queries which are dropped. The allowed range for LeakRate is 2 to 10. If LeakRate is set to zero, then no responses are 'leaked' by RRL. LeakRate leaves a chance for the victims in the same subnet as the forged IP address to get responses to their valid queries. The default value for LeakRate is 3. |
| TruncateRate | Specifies the rate at which the server responds with truncated responses. For queries that meet the criteria to be dropped due to RRL, the DNS server still responds with truncated responses once per TruncateRate queries. For example, if TruncateRate is 2, one in every 2 queries receives a truncated response. The TruncateRate parameter provides the valid clients a way to reconnect using TCP. The allowed range for TruncateRate is 2 to 10. If it is set to 0, then this behaviour is disabled. The default value is 2. |
| MaximumResonsesPerWindow | Specifies the maximum number of responses that the server sends to a subnet-domain address in a RRL time window. This puts an upper limit on responses in cases where the magnitude of attack is so high that even the leaked responses are enough to cause a reflection attack. The default value is 1024 responses per window. |
| Mode | Specifies the state of RRL on the DNS server. The acceptable values for this parameter are: Enable, or Disable, or LogOnly. If the mode is set to LogOnly the DNS server performs all the RRL calculations but instead of taking the preventive actions (dropping or truncating responses), it only logs the potential actions as if RRL were enabled and continues with the normal responses. The default value is Enable. |
Note: The Windows DNS server RRL implementation is based on the features prescribed by the RRL memo by Vernon Schryver and Paul Vixie, which has been interpreted and implemented by Windows DNS Server team .
Response Rate Limiting Exception Lists
Even on the DNS servers which have RRL enabled the administrators can identify some high priority domains, known benign subnets and dedicated server interfaces from which repeated queries of similar types may originate. Such examples include the health monitoring systems, interfaces serving secure internal networks or the FQDNs for newly released applications that are expected to have a spike of queries. To ensure that the RRL does not have any negative impact on their name resolution, the admin can add them to an RRL exception list. This can be done using following cmdlet
Add-DnsServerResponseRateLimitingExceptionlist -Name "SafeList1" -Fqdn "EQ,*.contoso.com"
Add-DnsServerResponseRateLimitingExceptionlist -Name "SafeInterface" -ServerInterface "EQ,20.0.0.1"
See More at Add-DnsServerResponseRateLimitingExceptionList
Call to Action
Now that you have learnt about Response Rate Limiting in Windows DNS Server 2016, we request you to try the feature and let us know your feedback. Also tell us how you plan to use RRL in your environment. Use the comment box below or mail us at windns-users@lists.cloudapp.net
Also See
Name Resolution Performance of a Recursive Windows DNS Server 2012 R2
Name Resolution Performance of Authoritative Windows DNS Server 2012 R2
What's New in DNS Server in Windows Server Technical Preview
Authored by: Kumar Ashutosh
Comments
- Anonymous
August 30, 2015
I'm very pleased to see this implemented.
Please consider backporting to Windows Server 2008 R2. Infrastructure can have a very long life. There is a precedent. WMF 5 has been backported even though mainstream support has ended. Even if it is at the level of an Optional update or hotfix. It helps Windows Server be a good network citizen.
Thank you. - Anonymous
September 03, 2015
One of the widely debated behaviour of an authoritative name servers is the nature of the response it - Anonymous
September 07, 2015
208 Microsoft Team blogs searched, 57 blogs have new articles. 263 new articles found searching from - Anonymous
September 23, 2015
This is very exiting and critical in a large environment.
Where are the logs stored when putting the Mode to Logonly or to Enable? It is critical to always understand the impact and communicate that before being told by the customer.
Thank you very much. - Anonymous
November 30, 2015
The comment has been removed - Anonymous
November 30, 2015
The comment has been removed