In message <3809dd3b-af63-492e-bc2d-e447ee4b3...@ogud.com>, Olafur Gudmundsson writes: > > > 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
NSEC3 is not a singlton. It is a quasi singleton record. Two chains may have names that hash to the same value which is why I said to check the parameters. Statistically this is extremely unlikely but it is easy to check to ensure that you are not removing from a different chain. Named already does this check when rebuilding NSEC3 chains after processing a UPDATE mesaage. > b) replacement of NSEC3PARM implies that the NSEC3âs matching old > NSEC3PARAM can be deleted. Multiple NSEC3PARAM records are permitted. A server only needs to pick one when generating a reply. There is zero requirement for a server to delete all NSEC3 records that make up a NSEC3 chain atomically. Named doesn't do this today and I have no intention of making the incremental management of NSEC/NSEC3 constuction / destruction do this. This work is deliberatly broken up to allow a server to appear to simultaneously answer queries, to rebuild/destroy NSEC/NSEC3 chains in zones and to accept new updates without having to rely on the OS supporting threads. NSEC3PARAM -> NSEC3 inference you are describing above depends on atomicity of changes which just do not happen and cannot be made to happen without detremental effects. > Olafur > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
