> On Mar 25, 2015, at 8:33 AM, Mark Andrews <ma...@isc.org> wrote: > > > In message <alpine.lsu.2.00.1503251055490.23...@hermes-1.csi.cam.ac.uk>, Tony > Finch writes: >> John Dickinson <j...@sinodun.com> wrote: >>> >>> I support this draft. One thing that jumped out to me was there appears >>> to be no mention of NSEC/NSEC3 chain management when adding/removing >>> records. >> >> Even if the slave is able to work out what the necessary changes are to >> the NSEC chain, the master is still going to have to send the new RRSIG >> records. So I don't think there would be much saving from adding special >> cases for NSEC and NSEC3. > > NSEC is a singleton record. Adding a new one indicates a implicit > deletion of any other NSEC record at that name. This does not > indicate that all NSEC deletes can be removed from the IXFR stream, > when constructing a MIXFR stream, only those with a matching addition. > > Adding a NSEC3 record causes a implicit deletion of the existing > NSEC3 with matching parameters. This does not indicate that all > NSEC3 deletes can be remove from the IXFR stream, when constructing > a MIXFR stream, only those with a matching addition.
The only cases where MIXFR can safe in the case of NSEC3 are a) add of updated NSEC3 with same owner name as singleton the old one is deleted b) replacement of NSEC3PARM implies that the NSEC3’s matching old NSEC3PARAM can be deleted. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
