Bug 873624 - bind: Backport Response Rate Limiting (DNS RRL) patch into Red Hat Enterprise Linux 6
bind: Backport Response Rate Limiting (DNS RRL) patch into Red Hat Enterprise...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind (Show other bugs)
Unspecified Unspecified
high Severity urgent
: rc
: ---
Assigned To: Tomáš Hozza
: ZStream
Depends On:
Blocks: 906312 1174953
  Show dependency treegraph
Reported: 2012-11-06 05:59 EST by Jan Lieskovsky
Modified: 2014-12-16 15:29 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1174953 (view as bug list)
Last Closed: 2013-11-14 05:48:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
graphical statistics of patch in action (15.49 KB, image/png)
2013-01-25 11:27 EST, Paul Wouters
no flags Details

  None (edit)
Description Jan Lieskovsky 2012-11-06 05:59:04 EST
Description of problem:
Originally, the CVE-2006-0987 identifier has been assigned to the following issue:

The default configuration of ISC BIND, when configured as a caching name server, allows recursive queries and provides additional delegation information to arbitrary IP addresses, which allows remote attackers to cause a denial of service (traffic amplification) via DNS queries with spoofed source IP addresses. 

This issue is covered in the bug #873618 (the bind package as shipped with Red Hat Enterprise Linux 6 is not affected by this issue in the default configuration).

But in the configuration where bind is configured to listen for requests from authorized clients, the DDoS attack might be possible.

Therefore the point of this bug is to request backport of DNS RRL patch suggested by Adam Tkac:

which would help mitigate the impact of DDoS attacks also for these configurations.

But since Red Hat Security Response Team would not consider this backport to be correcting a security flaw (its more a security hardening for a non-default configuration), it is reported under this record.

Version-Release number of selected component (if applicable):

Additional info:
See bug #873618 and its References for further details.
Comment 3 Paul Wouters 2012-11-09 11:16:54 EST
Note that it _is_ a security flaw.

Allowing our servers to become a functional part of an amplification attack is a security risk. It could damage the network the server is running in (as well as our reputation)

However, this is more a problem for bind when it is an authoritative server, not when it is a recursive server. The amplification bounces of the authoritative name servers, which _DO_ need to listen/answer to the world at large.

I believe it is prudent to apply the patch, and leave a commented out rate limit section in the named.conf file, so that _when_ people are being abused in an amplification attack, they have the option of simply enabling the rate limit option without the requirement for recompiles of a patched bind.

The patch has been tested on authoritatve servers powering large TLDs.
Comment 4 Kevin Fenzi 2013-01-24 15:44:58 EST
We just hit this today with the fedoraproject.org servers. ;( 

An official package with the patches would be most welcome. 

I can only imagine other places have hit this same issue, or will moving forward.
Comment 10 Paul Wouters 2013-01-25 11:27:26 EST
Created attachment 687546 [details]
graphical statistics of patch in action

success of the patch can be clearly seen here

Note You need to log in before you can comment on or make changes to this bug.