named fails to generate missing DNSSEC signatures for NSEC3 records generated by a previous instance
If NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If
named is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records generated by the previous
named instance will remain unsigned.
This is due to the fact that when
named is restarted, NSEC3 chain creation is started from scratch (since database iterator state is not maintained between restarts) and if a pre-existing NSEC3 record is found by
dns_nsec3_addnsec3(), it will first remove the old record and then re-add an identical one. This is not an issue in itself but the subsequent call to
do_one_tuple() involves invoking
dns_diff_appendminimal(), which in turn removes changes which cancel each other out from the diff structure. In the case of
dns_nsec3_addnsec3(), the diff structure in question is the one that is subsequently passed to
dns__zone_updatesigs(), which means that in order for any NSEC3 record to be (re)signed, it must be present in that diff structure; this will be the case for newly created NSEC3 records but not for these which were already present in the zone database; it will also not be an issue for records which were both pre-existing and signed before
named was restarted since their signatures would simply be preserved.
(Related to Support RT #13752)