Deprecation notice for NSEC3 salt

[Matthijs Mekking]

Hello BIND users,

Here is another deprecation notice. Following the Guidance for NSEC3 
Parameter Settings in, we will remove the option to specify salt for 
NSEC3 records. Per RFC 9276:

    Operators SHOULD NOT use a salt by indicating a zero-length salt
    value instead (represented as a "-" in the presentation format).

The reason for this is also explained in the RFC:

    In NSEC3 records are always implicitly "salted" by hashing the FQDN
    from each zone.  Thus, no single pre-computed table works to speed up
    dictionary attacks against multiple target zones. An attacker is
    always required to compute a complete dictionary per zone, which is
    expensive in both storage and CPU time.

And:

    Changing a zone's salt value requires the construction of a complete
    new NSEC3 chain.  This is true both when re-signing the entire zone
    at once and when incrementally signing it in the background where the
    new salt is only activated once every name in the chain has been
    completed.  As a result, re-salting is a very complex operation, with
    significant CPU time, memory, and bandwidth consumption.  This makes
    very frequent re-salting impractical and renders the additional salt
    field functionally useless.

Thus, I am notifying you that we intend to end support for the "nsec3 
salt-length" (inside dnssec-policy) option in named. Our plan is to mark 
them as deprecated in BIND 9.20, and remove them completely as of BIND 9.22.

Comments, questions and feedback are welcome.

Best regards,

Matthijs