Bugzilla – Bug 854109
VUL-0: CVE-2013-5661: bind: DNS response rate limiting can simplify cache poisoning attacks
Last modified: 2019-11-08 22:33:32 UTC
CVE-2013-5661 from RedHat bugzilla: 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. Affected systems: Bind versions 9.8 to 9.9 NSD version 3.2.15 Knot versions below 1.3.0 Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1038750 http://www.certa.ssi.gouv.fr/site/CERTA-2013-AVI-506/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5661
bugbot adjusting priority
Paul Vixie explaineswhy it is a good thing to leave the slip parameter at 2: http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/ I think we should follow his advice and close this bug, but leave the ultimate decision to the security team.
After above, we will not change our settings, administrators can do it themselves if they wish to.