From: =?utf-8?b?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Date: Thu, 16 May 2024 12:15:23 +0200
Subject: Document SIG(0) verification removal

(cherry picked from commit 654ba34d80b8b6ed805461d7ada2466f8c19a6f1)
---
 doc/arm/advanced.rst  | 18 +++---------------
 doc/arm/general.rst   |  6 ++----
 doc/arm/reference.rst |  4 ++--
 doc/arm/security.rst  |  4 ++--
 4 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/doc/arm/advanced.rst b/doc/arm/advanced.rst
index 4405b5c..f3325d9 100644
--- a/doc/arm/advanced.rst
+++ b/doc/arm/advanced.rst
@@ -537,7 +537,7 @@ zone).
 The TKEY process is initiated by a client or server by sending a query
 of type TKEY to a TKEY-aware server. The query must include an
 appropriate KEY record in the additional section, and must be signed
-using either TSIG or SIG(0) with a previously established key. The
+using either TSIG with a previously established key. The
 server's response, if successful, contains a TKEY record in its
 answer section. After this transaction, both participants have
 enough information to calculate a shared secret using Diffie-Hellman key
@@ -555,20 +555,8 @@ deletion" mode.
 SIG(0)
 ------
 
-BIND partially supports DNSSEC SIG(0) transaction signatures as
-specified in :rfc:`2535` and :rfc:`2931`. SIG(0) uses public/private keys to
-authenticate messages. Access control is performed in the same manner as with
-TSIG keys; privileges can be granted or denied in ACL directives based
-on the key name.
-
-When a SIG(0) signed message is received, it is only verified if
-the key is known and trusted by the server. The server does not attempt
-to recursively fetch or validate the key.
-
-SIG(0) signing of multiple-message TCP streams is not supported.
-
-The only tool shipped with BIND 9 that generates SIG(0) signed messages
-is ``nsupdate``.
+Support for DNSSEC SIG(0) transaction signatures was removed.
+This is a countermeasure for CVE-2024-1975.
 
 .. include:: managed-keys.rst
 .. include:: pkcs11.rst
diff --git a/doc/arm/general.rst b/doc/arm/general.rst
index d7b7c20..136e806 100644
--- a/doc/arm/general.rst
+++ b/doc/arm/general.rst
@@ -367,10 +367,8 @@ Notes
 .. [#rfc1035_2] CLASS ANY queries are not supported. This is considered a
    feature.
 
-.. [#rfc2931] When receiving a query signed with a SIG(0), the server is
-   only able to verify the signature if it has the key in its local
-   authoritative data; it cannot do recursion or validation to
-   retrieve unknown keys.
+.. [#rfc2931] Support for SIG(0) message verification was removed
+   as a countermeasure for CVE-2024-1975.
 
 .. [#rfc2874] Compliance is with loading and serving of A6 records only.
    A6 records were moved to the experimental category by :rfc:`3363`.
diff --git a/doc/arm/reference.rst b/doc/arm/reference.rst
index ecc84d4..f982e0a 100644
--- a/doc/arm/reference.rst
+++ b/doc/arm/reference.rst
@@ -5900,7 +5900,7 @@ The ``update-policy`` clause allows more fine-grained control over which
 updates are allowed. It specifies a set of rules, in which each rule
 either grants or denies permission for one or more names in the zone to
 be updated by one or more identities. Identity is determined by the key
-that signed the update request, using either TSIG or SIG(0). In most
+that signed the update request, using either TSIG. In most
 cases, ``update-policy`` rules only apply to key-based identities. There
 is no way to specify update permissions based on the client source address.
 
@@ -5957,7 +5957,7 @@ field), and the type of the record to be updated matches the ``types``
 field. Details for each rule type are described below.
 
 The ``identity`` field must be set to a fully qualified domain name. In
-most cases, this represents the name of the TSIG or SIG(0) key that
+most cases, this represents the name of the TSIG key that
 must be used to sign the update request. If the specified name is a
 wildcard, it is subject to DNS wildcard expansion, and the rule may
 apply to multiple identities. When a TKEY exchange has been used to
diff --git a/doc/arm/security.rst b/doc/arm/security.rst
index 817ebd0..92b1668 100644
--- a/doc/arm/security.rst
+++ b/doc/arm/security.rst
@@ -83,7 +83,7 @@ Limiting access to the server by outside parties can help prevent
 spoofing and denial of service (DoS) attacks against the server.
 
 ACLs match clients on the basis of up to three characteristics: 1) The
-client's IP address; 2) the TSIG or SIG(0) key that was used to sign the
+client's IP address; 2) the TSIG key that was used to sign the
 request, if any; and 3) an address prefix encoded in an EDNS
 Client-Subnet option, if any.
 
@@ -124,7 +124,7 @@ and no queries at all from the networks specified in ``bogusnets``.
 
 In addition to network addresses and prefixes, which are matched against
 the source address of the DNS request, ACLs may include ``key``
-elements, which specify the name of a TSIG or SIG(0) key.
+elements, which specify the name of a TSIG key.
 
 When BIND 9 is built with GeoIP support, ACLs can also be used for
 geographic access restrictions. This is done by specifying an ACL