### Summary
<!--
Concisely summarize the bug encountered,
preferably in one paragraph or less.
-->

### BIND versions affected
<!--
Make sure you are testing with the **latest** supported version of BIND.
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND

Paste the output of `named -V` here.
-->

### Preconditions and assumptions
<!--
Is a specific setup needed?

Please check the BIND Security Assumptions chapter in the ARM:
https://bind9.readthedocs.io/en/latest/chapter7.html#security-assumptions

E.g. DNSSEC validation must be disabled, etc.
E.g. Resolver must be configured to forward to attacker's server via DNS-over-TLS, etc.
E.g. Authoritative server must be configured to transfer specific primary zone.
E.g. Attacker must be in posession of a key authorized to modify at least one zone.
E.g. Attacker can affect system clock on the server running BIND.
-->

### Attacker's abilities
<!--
What resources does an attacker need to have under their control to mount this attack?

E.g. If attacking an authoritative server, does the attacked have to have prior
relationship with it? "The authoritative server under attack needs to
transfer a malicious zone from attacker's authoritative server via TLS."

E.g. If attacking a resolver, does the attacker need the ability to send
arbitrary queries to the resolver under attack? Do they need to _also_ control
an authoritative server at the same time?
-->


### Impact
<!--
Who or what is the victim of the attack and what is the impact?

Is a third party receiving many packets generated by a reflection attack?

If the affected party is the BIND server itself, please quantify the impact
on legitimate clients:
E.g. After launching the attack, the answers-per-second metric for legitimate
traffic drops to 1/1000 within the first minute of the attack.
-->


### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.

Even if a default configuration is affected, please include the full configuration
files _you were testing with_.

Example:
1. Use the _attached_ configuration file
2. Start the BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using the command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using the command `dnsperf -S1 -d attack-queries ...`
-->

1.
2.
3.

### What is the current *bug* behavior?

<!--
Examples:
Legitimate QPS drops 1000x.
Memory consumption increases out of bounds and the server crashes.
The server crashes immediately.
-->

### What is the expected *correct* behavior?

<!--
If the attack causes resource exhaustion, what do you think the correct
behavior should be? Should BIND refuse to process more requests?

What heuristic do you propose to distinguish legitimate and attack traffic?
-->

### Relevant logs
<!--
Please provide log files from your testing. Include full named logs and also
the output from any testing tools (e.g. dnsperf, DNS Shotgun, kxdpgun, etc.)

If multiple log files are needed, make sure all the files have matching timestamps
so we can correlate log events across log files.

In the case of resource exhaustion attacks, please _also_ include system monitoring
data. You can use https://gitlab.isc.org/isc-projects/resource-monitor/ to
gather system-wide statistics.
-->

### Coordination
- Does this issue affect multiple implementations?
<!--
Issues affecting multiple implementations require very careful coordination. We
have to make sure the information does not leak to the public until vendors are ready to
release fixed versions. If it is a multi-vendor issue, we need to know about the situation
as soon as possible to start the (confidential!) coordination process within
DNS-OARC and other suitable fora.

Please list implementations you have tested.
-->

- Have you shared the information with anyone else?
<!--
Have you informed other affected vendors? Or maybe submitted a paper for
review?
-->

- What is your plan to publicize this issue?
<!--
E.g. we plan to go public during conference XYZ on 20XX-XX-XX
-->

### Acknowledgements
<!--
Please specify whether and how you would like to be publicly credited with
discovering the issue. We normally use the format:
First_name Last_name, Company_or_Team.
-->

<!-- DO NOT modify the following two lines. -->

/label ~Bug ~Security
/confidential