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).
Impact
A remote, unauthenticated attacker can cause the named daemon to crash creating a denial of service condition.
Solution
Apply an update
Users who obtain BIND from a third-party vendor, such as their operating system vendor, should see the vendor information portion of this document for a partial list of affected vendors.
This vulnerability is addressed in ISC BIND versions 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 and 9.8.0-P2. Users of BIND from the original source distribution should upgrade to this version.
According to ISC: 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.