BIND 9.20 Brings Streamlined Core, Some New Features
Today, ISC is proud to release BIND 9.20.0, our newest stable branch.
Read postWe have been researching and testing a DNS vulnerability report called the DNSBomb (CVE-2024-33655). After extensive testing, we have concluded that this technique does not pose a significant threat to BIND 9 operators. Our testing showed that with recommended configurations:
The DNSBomb attack was described by Xiang Li from Tsinghua University NISL Lab and responsibly disclosed to multiple DNS software development teams for assessment. This is a pulsing denial-of-service attack (PDOS) that leverages features such as query rate limits, query timeouts, and maximum response size settings to create timed floods of responses using a maliciously designed authority and a vulnerable recursive resolver. Their attack also incorporates response amplification, by using specially-crafted zones on the authority to return large responses.
There are three critical steps to construct the DNSBomb attack:
After testing some variants of this attack vs BIND 9, we found multiple ways to limit or reduce the impact of DNSBomb on BIND 9 resolvers. Most of these are configured by default, but there are also rate limits that can be configured to further reduce the effectiveness of this attack.
These limits are effective against the DNSBomb attack:
clients-per-query
/ max-clients-per-query
are set by default to 10 and 100, respectively. They limit the total number of outstanding clients (requests) for any single query. In the worst case, there can be 100 outstanding requests.recursive-clients
is configured by default to 1000. This limits the total number of outstanding requests. After reaching 90% of this limit (i.e. 900 requests by default), the oldest requests are dropped and can no longer contribute to the effectiveness of this attack.responses-per-second
is a rate limit which can be configured to further mitigate this attack. It limits the number of UDP responses for a particular query per network segment.Amplification attacks are a common problem in the DNS. DNS responses are typically much larger than the corresponding queries, so the main difference between regular query/response patterns and abusive ones is the amplification factor. Wide variations in query volume can be seen under normal operation, so we look for amplification factors of at least two orders of magnitude when considering whether an amplifier is actually a potent attack vector.
Here’s the worst case scenario for a resolver with a default configuration under the DNSBomb attack:
The paper argues that this means a significant bandwidth amplification factor. While that may be true under ideal conditions, this attack doesn’t scale. Due to the recursive-clients limit (which defaults to 1000), any new requests will cause the oldest ones to be dropped, no longer contributing to the bandwidth amplification factor.
In other words, if the attacker sent 10k or 100k packets instead, the short data burst on the victim’s side would still be just 12 MB of data.
In real-world conditions, the attack is likely to be even less efficient, since the full impact would require that the attacker be the only client using this resolver and thus be able to utilize the entire recursive-clients limit for itself. If there are other clients, they’re likely using at least some of this quota, making the attack even less effective.
What's New from ISC