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)