Florian Maury and Mathieu Feuillet of the French Network and Information Security Agency (ANSSI in French) reported that the use of of response rate limiting techniques (such as DNS RRL feature available for Bind, NSD and Knot name servers) used as DNS amplification DoS attacks prevention can make DNS cache poisoning attacks easier. That is because certain requests form DNS resolvers to authoritative server will remain unanswered because of the RRL, which increases the time window during which attacker can flood DNS resolvers with spoofed responses in attempt to guess correct transaction id and source port number.
When using DNS RRL feature with Bind, NSD or Knot, researchers recommend changing the value of slip configuration parameter from 2 to 1 to address this problem. The slip parameter defines the behavior of the name server when RRL mechanism detects attack. It instructs name server to respond 1 of slip requests with a response with truncation (TC) bit set and not respond other requests. The default value of 2 means that half of all requests are answered, while 1 causes name server to send response to all requests. Slipped responses with TC bit set are shorter than normal responses (matching request size rather than significantly exceeding it) and instruct resolver to retry their request using TCP instead of UDP.
Quick outline of the attack:
1) attacker chooses DNS resolver R and domain D they want to poison
2) attacker sends large amount of DNS requests to authoritative nameserver(s) for domain D using spoofed source IP address of R; these authoritative nameservers need to be configured to use RRL
3) requests trigger rate limiting protection, causing some of the subsequent requests originating form R to be dropped without any answer
4) attacker makes R attempt to do resolution of domain D
5) if authoritative nameserver for D does not respond R's legitimate requests, attacker can send spoofed replies using authoritative nameserver's source IP address and attempt to guess correct transaction id and source port without having to race against reply form the authoritative nameserver
DNS response rate limiting feature, as implemented for bind, nsd and knot name servers:
This feature was added to Red Hat Enterprise Linux 6 bind packages via RHSA-2013:0550:
Only configurations with the rate limiting enabled are affected by this issue. Response rate limiting feature is currently not available in bind and bind97 packages in Red Hat Enterprise Linux 5 (and earlier).
(In reply to Tomas Hoger from comment #0)
> When using DNS RRL feature with Bind, NSD or Knot, researchers recommend
> changing the value of slip configuration parameter from 2 to 1 to address
> this problem.
Following blog posts from ISC and Paul Vixie (on of the RRL authors) take a closer look at this recommendation from ANSSI researchers:
They acknowledge that the use of RRL with the default slip value can make cache poisoning attacks easier, the argue against changing the default to 1. Even with RRL with slip=2 enabled, poisoning attack is expected to require excessive amount of network traffic to succeed (16 hours of 100Mbps of forged traffic). slip=1 changes that back from hours to days, at the cost of significantly reducing benefits of RRL protection. According to Paul Vixie:
Real operational experience has shown that "slip=2" makes a server
unattractive as a denial-of-service reflector, whereas not so "slip=1".
Due to these reason, RRL upstream does not believe that benefits of slip=1 outweigh its drawbacks and hence does not plan to change the default value of this option.
Red Hat currently does no plan to diverge from upstream and use different default in bind packages in Red Hat Enterprise Linux. Users enabling RRL in bind can change the default value if it does not suit the needs of their deployment.
Red Hat does not currently plan to change the default value of the slip parameter of the DNS response rate limiting (DNS RRL) feature in bind packages shipped with Red Hat Enterprise Linux. Refer to Red Hat Bugzilla bug 1038750 for additional details.
NSD upstream blog post:
*** Bug 987360 has been marked as a duplicate of this bug. ***