Rate Limits in BIND 9 Effective vs. DNSBomb Vulnerability

BIND 9 is Unaffected by the DNSBomb

We 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 packet amplification factor for the client(s) is 1x (i.e. none).
• The novel part of this attack – spreading out the queries over time, and then tricking the resolver into responding within a short time window – is already sufficiently mitigated by existing limits that are in place.

The DNSBomb Attack

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:

1. Accumulating DNS queries (by extending the timeout window to delay responses artificially)
2. Amplifying responses (using query aggregation on the authoritative server and domains specially crafted to return large answers)
3. Collecting and “pulsing” responses to the target resolver in large batches

Testing the Limits in BIND 9

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.

Notes on the Amplification Factor

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 attacker (spoofing the victim’s address) sends 1000 packets over time (up to 10 seconds), while the authoritative server (under the attacker’s control) withholds the answer for that amount of time.
• Once the attacker’s authoritative server responds, the resolver answers all outstanding queries for the attacker’s domain.
• Assuming the answer is crafted to utilize the maximum packet size that will be transmitted over UDP, each answer could be 1232 bytes long. For 1000 outstanding queries, the total amount of data sent could be up to 12 MB sent within a very short time window.

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.

References

• ISC’s BIND 9 GitLab issue #4398. This issue will be hidden until the original reporter’s technical paper is published, currently planned for May 22, 2024 at the IEEE Symposium on Security and Privacy.
• The reporter, Xiang Li’s, homepage: https://lixiang521.com/
• Network and Information Security Laboratory, Tsinghua University: https://netsec.ccert.edu.cn/
• ISC’s Software Defect and Security Vulnerability Disclosure Policy
• ISC’s CVSS Scoring Guidelines
• The BIND 9 Administrator Reference Manual includes a section on deploying BIND securely. We assume these best practices are followed in assessing vulnerabilities.