> It is not possible to configure NSEC3 as a default in named.conf (on a > per zone basis), is it? I would welcome such a feature.
I considered it, but bogged down on issues like what to do if you have nsec3 parameters set a certain way in named.conf, then change them in the running zone, then restart your server--it will detect the mismatch, but does it restore the original nsec3 chain, or yield to the zone contents? Ultimately decided it was better to keep the nsec3 configuration in only one place, the zone itself. > I also find it a bit strange that BIND decides to go for NSEC, even when > the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1). I think the thing that's confusing there is the name "NSEC3RSASHA1". There's no difference between algorithm 7 and algorithm 5 (RSASHA1). The use of a new algorithm number for a previously-existing algorithm is sort of a signaling mechanism: it tells older resolvers (e.g., BIND 9.5 and earlier) that you're using a newer version of the DNSSEC specification than they're equipped to deal with . But it doesn't mean NSEC3 is required, or even expected. The use of "NSEC3" in the human-readable algorithm name is rather misleading (it certainly confused me at first). Later algorithms such as RSASHA256 also support NSEC3, but they don't say so in their names, which I think leads to less confusion around this point. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
