Commit a0f0383a79 for bind

commit a0f0383a793f4a800da7e77ea5941824d92dd0a8
Author: Petr Špaček <pspacek@isc.org>
Date:   Tue Nov 3 14:57:43 2026 +0100

    Update Bug and Security_issue templates

    Shorten texts, link to Threat Model, clarify AI usage rules.

diff --git a/.gitlab/issue_templates/Bug.md b/.gitlab/issue_templates/Bug.md
index f47bed0095..857a7148ec 100644
--- a/.gitlab/issue_templates/Bug.md
+++ b/.gitlab/issue_templates/Bug.md
@@ -1,49 +1,62 @@
 <!--
-If the bug you are reporting is potentially security-related - for example,
-if it involves an assertion failure or other crash in `named` that can be
-triggered repeatedly - then please make sure that you make the new issue
-confidential by clicking the checkbox at the bottom!
+For potential security problems (e.g., repeatable assertions or crashes in `named`),
+use Security_issue template instead!
+
+BIND 9 threat model https://bind9.readthedocs.io/en/latest/chapter7.html#threat-model
+defines what constitutes a security issue.
 -->

 <!--
-If you found the problem in BIND 9 using generative AI tools and you have verified it
-yourself to be true: write the report yourself and explain the problem as you
-have learned it. This makes sure the AI-generated inaccuracies and invented
-issues are filtered out early before they waste more people's time.  Even if you
-write the report yourself, you must make sure to reveal the fact that
-generative AI was used in your report.
-
-We ban users immediately who submit fake reports to the project.
+If you used generative AI to find the bug, verify it yourself, explain it in your
+own words, and disclose AI use to avoid wasting time on AI errors or inventions.
+
+Provide ONLY the information requested by this template, with the minimum
+detail needed to reproduce and assess the issue.
+No code flow explanation, no affected version ranges, no history of code changes,
+no CVSS scoring, etc. Our team handles all that.
+
+Fake reports result in an immediate ban.
 -->

 ### Summary

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

 ### BIND version affected
 <!--
-Make sure you are testing with the **latest** supported version of BIND
-for a given branch. Many bugs have been fixed over time!
+Test the **latest** supported BIND version for your branch to rule out fixed bugs.

-See https://kb.isc.org/docs/supported-platforms for the current list.
-The latest source is available from https://www.isc.org/download/#BIND
+Supported versions: https://kb.isc.org/docs/supported-platforms
+Latest source: https://www.isc.org/download/#BIND

-Paste the output of `named -V` here.
+Paste `named -V` output.
+-->
+
+### Relevant configuration files
+
+<!--
+Paste relevant configuration files in code blocks (```).
+Attach as files if large.
+
+Hide secrets with `named-checkconf -px`.
 -->

 ### Steps to reproduce

 <!--
-This is extremely important! Be precise and use itemized lists, please.
+Give precise, minimal, itemized steps.
+
+Minimize the reproducer. Use named instances on one machine instead of multiple
+containers whenever possible. Use 10.53.0.x IP addresses configured by
+bin/tests/system/ifconfig.sh as needed.

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

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

 1.
@@ -58,17 +71,8 @@ Example:

 <!-- What you should see instead. -->

-### Relevant configuration files
-
-<!-- Paste any relevant configuration files here - please use code blocks (```)
-to format console output. If submitting the contents of your
-configuration file in a non-confidential issue, it is advisable to
-obscure key secrets; this can be done automatically by using
-`named-checkconf -px`. -->
-
 ### Relevant logs

-<!-- Paste any relevant logs here - please use code blocks (```) to format console
-output, logs, and code, as it's very hard to read otherwise. -->
+<!-- Paste relevant logs, console output, and code in code blocks (```). -->

 /label ~Bug
diff --git a/.gitlab/issue_templates/Security_issue.md b/.gitlab/issue_templates/Security_issue.md
index 4ce2b8dba7..a1bb80773c 100644
--- a/.gitlab/issue_templates/Security_issue.md
+++ b/.gitlab/issue_templates/Security_issue.md
@@ -1,127 +1,129 @@
 <!--
-If you found the problem using generative AI tools and you have verified it
-yourself to be true: write the report yourself and explain the problem as you
-have learned it. This makes sure the AI-generated inaccuracies and invented
-issues are filtered out early before they waste more people's time.  Even if you
-write the report yourself, you must make sure to reveal the fact that the
-generative AI was used in your report.
-
-As we take security reports seriously, we investigate each report with
-priority. This work is both time- and energy-consuming and pulls us away from
-doing other meaningful work. Fake and otherwise made-up security problems
-effectively prevent us from doing real project work and make us waste time and
-resources.
-
-We ban users immediately who submit fake reports to the project.
+If you used generative AI to find the bug, verify it yourself, explain it in your
+own words, and disclose AI use to avoid wasting time on AI errors or inventions.
+
+Provide ONLY the information requested by this template, with the minimum
+detail needed to reproduce and assess the issue.
+No code flow explanation, no affected version ranges, no history of code changes,
+no CVSS scoring, etc. Our team handles all that.
+
+Security reports receive priority.
+Fake reports waste resources and delay other project work, and result in an
+immediate ban.
 -->

 ### Summary
 <!--
-Concisely summarize the bug encountered,
-preferably in one paragraph or less.
+Summarize the bug, 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
+Test the **latest** supported BIND version.
+Supported versions: https://kb.isc.org/docs/supported-platforms
+Latest source: https://www.isc.org/download/#BIND

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

 ### Preconditions and assumptions
 <!--
-Is a specific setup needed?
-
-Please check the Threat Model section in the ARM:
+Check the Threat Model:
 https://bind9.readthedocs.io/en/latest/chapter7.html#threat-model

-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 possession of a key authorized to modify at least one zone.
-E.g. Attacker can shift the system clock on the server running BIND, e.g., via NTP.
+Is a specific setup needed?
+
+Examples:
+- DNSSEC validation disabled.
+- Resolver forwards to attacker's server via DNS-over-TLS.
+- Authoritative server transfers a specific primary zone.
+- Attacker holds a key authorized to modify a zone.
+- Attacker can shift the BIND server's clock, e.g., via NTP.
 -->

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

-E.g. If attacking an authoritative server, does the attacker 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."
+For authoritative servers, is a prior relationship required? E.g., the target
+must transfer a malicious zone from the 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?
+For resolvers, must the attacker send arbitrary queries? Must they _also_
+control an authoritative server?
 -->


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

-Is a third party receiving many packets generated by a reflection attack?
+Does a third party receive many packets from 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.
+For attacks on BIND itself, quantify the impact on legitimate clients.
+E.g., legitimate answers per second drop to 1/1000 within the first attack minute.

 Compare the impact with the Threat Model baselines over the same transport.
 -->


+### Relevant configuration files
+
+<!--
+Paste relevant configuration files in code blocks (```).
+Attach as files if large.
+
+Hide secrets with `named-checkconf -px`.
+-->
+
 ### Steps to reproduce
 <!--
-This is extremely important! Be precise and use itemized lists, please.
-Source code analysis alone is not sufficient; provide a reproducer against a
-released version.
+Give precise, minimal, itemized steps.
+Provide a reproducer against a released version; source analysis alone is insufficient.
+
+Minimize the reproducer. Use named instances on one machine instead of multiple
+containers whenever possible. Use 10.53.0.x IP addresses configured by
+bin/tests/system/ifconfig.sh as needed.

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

 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. Use the attached configuration.
+2. Start BIND: `named -g -c named.conf ...`
+3. Simulate legitimate clients: `dnsperf -S1 -d legit-queries ...`
+4. Simulate attack traffic: `dnsperf -S1 -d attack-queries ...`
 -->

 1.
 2.
 3.

-### What is the current *bug* behavior?
+### Actual insecure behavior

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

-### What is the expected *correct* behavior?
+### Expected secure behavior

 <!--
-If the attack causes resource exhaustion, what do you think the correct
-behavior should be? Should BIND refuse to process more requests?
+Optional. Leave empty if unsure.
+
+For resource exhaustion, how should BIND behave? Refuse further requests?

-What heuristic do you propose to distinguish legitimate and attack traffic?
+What heuristic could 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.)
+Include full named logs and test tool output (e.g., dnsperf, DNS Shotgun, kxdpgun).

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

-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.
+For resource exhaustion, _also_ include system monitoring data, e.g., from
+https://gitlab.isc.org/isc-projects/resource-monitor/.
 -->

 ### Coordination
@@ -133,24 +135,23 @@ release fixed versions. If it is a multi-vendor issue, we need to know about the
 as soon as possible to start the (confidential!) coordination process within
 DNS-OARC and other suitable fora.

-Please list implementations you have tested.
+List implementations tested.
 -->

 - Have you shared the information with anyone else?
 <!--
-Have you informed other affected vendors? Or maybe submitted a paper for
-review?
+E.g., informed affected vendors or 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
+E.g., disclose at 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:
+Specify whether and how to credit you publicly for discovering the issue.
+Usual format:
 First_name Last_name, Company_or_Team.
 -->