]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
Update documentation wrt key algorithms
authorMatthijs Mekking <matthijs@isc.org>
Fri, 11 Feb 2022 08:48:36 +0000 (09:48 +0100)
committerMatthijs Mekking <matthijs@isc.org>
Wed, 16 Feb 2022 09:25:30 +0000 (10:25 +0100)
Add a note to the DNSSEC guide and to the ARM reference that A ZSK/KSK
pair used for signing your zone should have the same algorithm.

This commit also updates the 'dnssec-policy/keys' example to use the
slightly more modern 'rsasha256' algorithm.

(cherry picked from commit 7365400610b60390cbd4704c23bd6477a095d558)

doc/arm/reference.rst
doc/dnssec-guide/signing.rst

index 5a0ad1b91c4024d456d65f18a880cacd4a88a8a9..0bf87b74deffc3e917ebef02e98ab46d0add0549 100644 (file)
@@ -4936,7 +4936,7 @@ The following options can be specified in a ``dnssec-policy`` statement:
     ::
 
         keys {
-            ksk key-directory lifetime unlimited algorithm rsasha1 2048;
+            ksk key-directory lifetime unlimited algorithm rsasha256 2048;
             zsk lifetime P30D algorithm 8;
             csk lifetime P6MT12H3M15S algorithm ecdsa256;
         };
@@ -4972,6 +4972,8 @@ The following options can be specified in a ``dnssec-policy`` statement:
     number.  An optional second parameter specifies the key's size in
     bits.  If it is omitted, as shown in the example for the second and
     third keys, an appropriate default size for the algorithm is used.
+    Each KSK/ZSK pair must have the same algorithm. A CSK combines the
+    functionality of a ZSK and a KSK.
 
   ``purge-keys``
     This is the time after when DNSSEC keys that have been deleted from
index c25b1c401fe67c53d26294c2f81dad2e66f72a90..ea920801b59f48194ae5bf2c29ef477a9688fb30 100644 (file)
@@ -762,9 +762,10 @@ The policy has multiple parts:
 -  The ``keys`` clause lists all keys that should be in the zone, along
    with their associated parameters. In this example, we are using the
    conventional KSK/ZSK split, with the KSK changed every year and the
-   ZSK changed every two months. We have used one of the two mandatory
-   algorithms for the keys. (The ``default`` DNSSEC policy sets a CSK
-   that is never changed.)
+   ZSK changed every two months (the ``default`` DNSSEC policy sets a
+   CSK that is never changed). Keys are created using the
+   ECDSAPS256SHA256 algorithm; each KSK/ZSK pair must have the same
+   algorithm. A CSK combines the functionality of a ZSK and a KSK.
 
 -  The parameters ending in ``-ttl`` are, as expected, the TTLs of the
    associated records. Remember that during a key rollover,