Re: [DNSOP] A new version of mixfr

Frederico A C Neves <fneves@registro.br> Thu, 29 March 2018 18:17 UTC

Return-Path: <fneves@registro.br>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81AE12E037 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 11:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8x1wHyXVuAN for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 11:17:27 -0700 (PDT)
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF2212DFDB for <dnsop@ietf.org>; Thu, 29 Mar 2018 11:17:27 -0700 (PDT)
Received: by clone.registro.br (Postfix, from userid 1000) id 3050927775D; Thu, 29 Mar 2018 15:17:25 -0300 (BRT)
Date: Thu, 29 Mar 2018 15:17:25 -0300
From: Frederico A C Neves <fneves@registro.br>
To: Mark Andrews <marka@isc.org>
Cc: Matthijs Mekking <matthijs@pletterpet.nl>, dnsop@ietf.org
Message-ID: <20180329181725.GE62218@registro.br>
References: <d7c4fc25-9d4b-d934-bad3-61e7b8364ca2@pletterpet.nl> <20180328150651.GQ62218@registro.br> <39423F2A-5D0A-435C-85A7-46813D001198@isc.org> <20180328211209.GA62218@registro.br> <20180328220510.GB94914@registro.br> <A790C5A6-560B-4B72-9049-84E57982A7EF@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A790C5A6-560B-4B72-9049-84E57982A7EF@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uRDQI8jt6JqqNU-LYq7igKtSvQQ>
Subject: Re: [DNSOP] A new version of mixfr
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2018 18:17:29 -0000

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 <fneves@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