Hi Havard,

> 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). 

I'm not sure what you mean by "which caused IXFR to miss the update". As
far as I can remember, at the time the issue was that removing the
record would result in the IXFR not to include the removal. But marking
it removed allowed the IXFR to detect its deletion.

> 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?

zone_publish_nsec3param() is also called from tools_input() when a
signconf is reread. When the signer is commanded to update a zone this
will trigger.

I have been testing today with the DNS output adapter to provoke an
incorrect IXFR but I haven't had any success so far.

If you still have a handle on the var/../tmp/<zone>.ixfr file I'd like
to see it. Perhaps the <zone>.backup2 file as well. But that has to be
from the time of the error to be useful.

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

It is now.

Regards,
Yuri


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

Reply via email to