> On 29 Mar 2018, at 9:05 am, Frederico A C Neves <fne...@registro.br> wrote: > > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote: >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote: >>> No. You can have multiple nsec3 chains in a zone at the same time. Only one >>> is active. Some may be incomplete. >>> >>> Named builds and destroys chains incrementally to avoid large changes. >>> >>> Timely ness of changes is more important than volume of changes. >> >> As I stated down on this thread this behaviour is the one that is >> already supported by IXFR. For large zones, on large anycast networks, >> the volume of changes on the wire is important. The current aproach is >> impractical. > > Perhaps this text is more specific and address the incremental re-salt > scenario and even improve it after the new chain in already in place > at the time of the removal of the old one. > > 3.1 Implicit DNSSEC deletions > > When an NSEC3PARAM is deleted or replaced, the MIXFR client MUST also > remove all existing NSEC3 records on the zone that form the chain > related to the deleted or replaced salt. > > Fred
Firstly we should just say “DO NOT CHANGE NSEC3PARAM” as it is POINTLESS!!!! Secondly you lose the ability to determine is the MIXFR is still in sync if you do that. Currently named requires that all delete operations in IXFR MUST find the record in the zone and that all add operations MUST NOT find a existing record. If either condition fails then named falls back to a full AXFR of the zone as we know the zone contents are no longer in sync. That property needs to be preserved by this implementation. You also need to be able to extract a MIXFR stream from a IXFR stream (as that is what gets recorded to disk). I don’t believe that will be possible from a arbitrary IXFR stream. Adding constraints like “the master server MUST delete all NSEC3 records when it deletes the NSEC3PARAM would make it work but then you have to deal with time to record the delta etc. Removing all RRSIGs works because that work is REQUIRED to be performed when a RRset is changed and that has issues with offline DNSKEY management. Mark -- 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
