it looks like the earlier problem I've had with a failure to remove
the old NSEC3PARAM resource records in a re-salt event is back again,
this time with OpenDNSSEC 1.4.10.

I'm seeing zones on my public master with 2 NSEC3PARAM resource
records, the oldest one being published last, and this causes BIND's
dnssec-verify to claim that all the NSEC3 records in the zone are
missing.  Bumping the SOA version on the hidden master causes a
re-sign and clears the problem, and this removes the extraneous
NSEC3PARAM record and causes dnssec-verify from BIND to be happy with
the zone again.  However, "this should not happen".

The earlier change which was supposed to fix this problem was


It looks like zone_del_nsec3params() is now responsible for marking
all NSEC3PARAM records with "is_removed = 1" (instead of outright
removing them, which caused IXFR to miss the update).  However, this
function appears to only be called from zone_publish_nsec3param(),
which in turn appears only to be called from zone_recover2(), which
has the header comment "Recover zone from backup."  So where does a
re-salt event occur in the code, and what piece of code takes
responsibility for calling zone_del_nsec3params() when that happens?

It looks like OpenDNSSEC-778 needs to be re-opened...


- HÃ¥vard
Opendnssec-user mailing list

Reply via email to