upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-05-27 12:13:20 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Document SIG(0) verification removal

Browse source
This commit is contained in:
Petr Špaček 2024-05-16 12:15:23 +02:00 committed by Nicki Křížek
parent bef3d2cca3
commit 33007e302d
No known key found for this signature in database
GPG key ID: 01623B9B652A20A7
5 changed files with 9 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
doc/arm/general.rst
View file

@ -391,10 +391,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 part of the mitigation of 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`.

2
doc/arm/intro-security.inc.rst
View file

@ -47,7 +47,7 @@ or ports come preconfigured with local (loopback address) security preconfigured
If ``rndc`` is being invoked from a remote host, further configuration is required.
The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically
change the contents of the zone file(s). ``nsupdate`` access and security may be controlled
using ``named.conf`` :ref:`statements or using TSIG or SIG(0) cryptographic methods <dynamic_update_security>`.
using ``named.conf`` :ref:`statements or via the TSIG cryptographic method <dynamic_update_security>`.
Clearly, if the remote hosts used for either ``rndc`` or DDNS lie within a network entirely
under the user's control, the security threat may be regarded as non-existent. Any implementation requirements,
therefore, depend on the site's security policy.

4
doc/arm/reference.rst
View file

@ -7450,7 +7450,7 @@ the zone's filename, unless :any:`inline-signing` is enabled.
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 TSIG. In most
cases, :any:`update-policy` rules only apply to key-based identities. There
is no way to specify update permissions based on the client source address.
@ -7507,7 +7507,7 @@ the zone's filename, unless :any:`inline-signing` is enabled.
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

4
doc/arm/security.inc.rst
View file

@ -85,7 +85,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.
@ -126,7 +126,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

16
doc/arm/sig0.inc.rst
View file

@ -12,17 +12,5 @@
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 :iscman:`nsupdate`.
Support for DNSSEC SIG(0) transaction signatures has been removed.
This is a countermeasure for CVE-2024-1975.