On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote: > > > 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.
AFAIK there is nothing on the current logic that a compliant server implementation would not preserve this property for a compliant client that expects it. > 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. You are right if what you have is only the stream of IXFRs. But a compliant server implementation at the time it updates the zone - being looking for differences of a zonefile, processing Dynamic Updates or reading an adequate jornal of updates - it will accordingly produce the IXFR and the MIXFR to be recorded on disk. Starting with the current zone representation and a stream of backward IXFRs allow you do first get to the past zone representation, I mean applying the IXFRs backward, and then start to produce the respective MIXFRs. Awkward, very unlikely implementation for a compliant MIXFR server, but possible. Fred _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
