Why salt of NSEC3 record should be made public?

Question

I'm wondering why NSEC3 record should include salt? I can't imagine why and how resolvers use salt?

Answer 1

The salt used in the NSEC3 case can change over time. It is even recommended that it changes. Hence at any given point in time you can have 2 NSEC3 records having been computed using a different salt.

See https://www.rfc-editor.org/rfc/rfc5155#appendix-C.1

There MUST be at least one complete set of NSEC3 RRs for the zone
using the same salt value.

The salt SHOULD be changed periodically to prevent pre-computation using a single salt. It is RECOMMENDED that the salt be changed for
every re-signing.

It is even more detailed after:

Note that this could cause a resolver to see RRs with different salt values for the same zone. This is harmless, since each RR stands alone (that is, it denies the set of owner names whose hashes, using the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 RR) -- it is only the server that needs a complete set of NSEC3 RRs with the same salt in order to be able to answer every possible query.

There is no prohibition with having NSEC3 RRs with different salts within the same zone. However, in order for authoritative servers to be able to consistently find covering NSEC3 RRs, the authoritative server MUST choose a single set of parameters (algorithm, salt, and
iterations) to use when selecting NSEC3 RRs.

The salt is not used to compute the NSEC3 record, it is used, with the name being proved as non existing, to be hashed, see https://www.rfc-editor.org/rfc/rfc5155#section-5 for the full algorithm.

A reading of https://www.rfc-editor.org/rfc/rfc7129 can help, section 5.5 for example. The resolver needs to hash the name itself (hence needs to know the hash algorithm, the salt value and the number of iterations, which are all in the NSEC3 record), to see which NSEC3 records apply.

With all details in the above reference, for the query x.2.example.org TXT a reply being:

15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. (
    NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG
           DNSKEY NSEC3PARAM )

   1avvqn74sg75ukfvf25dgcethgq638ek.example.org. (
       NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ )

   75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. (
    NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG )

here what happens inside the resolver:

The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1".
Checking this hash on the first NSEC3 yields that it does not fall in between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" to "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3, the answer is also negative: the hash sorts outside the interval described by "1avvqn74sg75ukfvf25dgcethgq638ek" and "75b9id679qqov6ldfhd8ocshsssb6jvq". And, the third NSEC3, with interval "75b9id679qqov6ldfhd8ocshsssb6jvq" to
"8555t7qegau7pjtksnbchg4td2m0jnpj" also isn't of any help.

And then the resolver will with the above discover the closest encounter, by doing:

The resolver keeps hashing increasingly shorter names from the query name until an owner name of an NSEC3 matches. This owner name is the closest encloser.

Hence in short the validating resolver needs the hash to do all of this.