CVE-2011-1910: Large RRSIG RRsets and Negative Caching Can Crash named
  • 01 Oct 2018
  • 3 Minutes to read
  • Contributors
  • Dark
  • PDF

CVE-2011-1910: Large RRSIG RRsets and Negative Caching Can Crash named

  • Dark
  • PDF

Article summary

Large RRSIG RRsets and Negative Caching Can Crash named

A BIND 9 DNS server set up to be a caching resolver is vulnerable to a user querying a domain with very large resource record sets (RRSets) when trying to negatively cache a response. This can cause the BIND 9 DNS server (named process) to crash.



Document Version: 1.5

Posting Date: 26 May 2011

Program ImpactedBIND

Versions Affected

9.4: 9.4-ESV-R3, -R4, -R5b1 9.5: 9.5.3b1, 9.5.3rc1 (end-of-life) 9.6: 9.6.3, 9.6-ESV-R2, -R3, -R4, -R5b1 9.7: 9.7.1, 9.7.1-P1, -P2, 9.7.2, 9.7.2-P1, -P2, -P3, 9.7.3, 9.7.4b1 9.8: 9.8.0, 9.8.0-P1, 9.8.1b1

Severity: High

Exploitable: Remotely


DNS systems use negative caching to improve DNS response time. This will keep a DNS resolver from repeatedly looking up domains that do not exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the negative cache.

The authority data will be cached along with the negative cache information. These authoritative “Start of Authority” (SOA) and NSEC/NSEC3 records prove the nonexistence of the requested name/type. In DNSSEC, all of these records are signed; this adds one additional RRSIG record, per DNSSEC key, for each record returned in the authority section of the response.

In this vulnerability, very large RRSIG RRsets included in a negative response can trigger an assertion failure that will crash named (BIND 9 DNS) due to an off-by-one error in a buffer size check.

The nature of this vulnerability would allow remote exploit. An attacker can set up a DNSSEC signed authoritative DNS server with large RRSIG RRsets to act as the trigger. The attacker would then find ways to query an organization’s caching resolvers for non-existent names in the domain served by the bad server, getting a response that would “trigger” the vulnerability. The attacker would require access to an organization’s caching resolvers; access to the resolvers can be direct (open resolvers), through malware (using a BOTNET to query negative caches), or through driving DNS resolution (a SPAM run that has a domain in the E-mail that will cause the client to perform a lookup).

DNSSEC does not need to be enabled on the resolver for it to be vulnerable.

 CVSS Score: Base 7.8


For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit:


Restricting access to the DNS caching resolver infrastructure will provide partial mitigation. Active exploitation can be accomplished through malware or SPAM/Malvertizing actions that will force authorized clients to look up domains that would trigger this vulnerability.

Active Exploits: This issue has caused unintentional outages.


Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2 or the latest fixed version of the software.

See our BIND Software Downloads page to get the latest version:

Note: Engineering has confirmed that 9.6.2-P3 is unaffected.

Credits Thanks to Frank Kloeker and Michael Sinatra for getting the details of this issue to the DNS Operations community and to Michael Sinatra, Team Cymru, and other community members for testing.   Document Revision History

  • Version 1.0 - 26 May 2011: Updated/corrected description
  • Version 1.1 - 27 May 2011: Published 9.4-ESV-P1 to the website and ftp
  • Version 1.2 - 27 May 2011: Updated, corrected text, and added clarifications based on questions to
  • Version 1.3 - 27 May 2011: Added VU#
  • Version 1.4 - 14 Jun 2011: Clarified versions affected
  • Version 1.5 - 20 Jun 2011: Link to CI Lab's translation to Chinese

Do you have questions? Questions regarding this advisory should go to

Do you need software support? Questions on ISC's Support services or other offerings should be sent to More information on ISC's support and other offerings is available at:

ISC Software Defect and Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found in our Software Defect and Security Vulnerability Disclosure Policy.

Legal Disclaimer

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time.

A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.