Hi, 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 https://github.com/opendnssec/opendnssec/commit/033021ff3736cae867cd6f57c8acd05600da5590 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... Regards, - HÃ¥vard _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
