NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)

[Evan Hunt]

> 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 -- each at isc.org
Internet Systems Consortium, Inc.