Re: [DNSOP] A new version of mixfr

Frederico A C Neves <fneves@registro.br> Wed, 28 March 2018 21:12 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 05B76127136 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 14:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 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] 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 X8cPoxR_0x22 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 14:12:11 -0700 (PDT)
Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0: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 BB503126B6D for <dnsop@ietf.org>; Wed, 28 Mar 2018 14:12:11 -0700 (PDT)
Received: by clone.registro.br (Postfix, from userid 1000) id 4BFE12A4B23; Wed, 28 Mar 2018 18:12:09 -0300 (BRT)
Date: Wed, 28 Mar 2018 18:12:09 -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: <20180328211209.GA62218@registro.br>
References: <d7c4fc25-9d4b-d934-bad3-61e7b8364ca2@pletterpet.nl> <20180328150651.GQ62218@registro.br> <39423F2A-5D0A-435C-85A7-46813D001198@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39423F2A-5D0A-435C-85A7-46813D001198@isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nrZHAxCmAnhOevNAAPeUHtzPgec>
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: Wed, 28 Mar 2018 21:12:14 -0000

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.

Fred

> 
> -- 
> Mark Andrews
> 
> > On 29 Mar 2018, at 02:06, Frederico A C Neves <fneves@registro.br> wrote:
> > 
> > Hi Matthijs,
> > 
> >> On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> >> All,
> >> 
> >> It's been a while, but I have put up a new version of the MIXFR draft:
> >> 
> >>     https://tools.ietf.org/html/draft-mekking-mixfr-02
> >> 
> >> The IETF 101 Hackathon lead to the revival of this draft.
> >> 
> >> Changes after the three year sleep:
> >> 
> >> - I removed the IXFR Gone Wild section. This document should focus in 
> >> the in-band transfer improvements. I know there are others who like to 
> >> see and work on a new DNS transfer protocol, but one does not exclude 
> >> the other.
> >> - Intended status: Standards track.
> >> - Added a clarification from Bob Harold about class ANY (from 2015).
> >> - Remove ambiguous "Delete All RRsets of a Type".
> >> - Affiliation changes.
> >> 
> > 
> > Thanks for bringing this back. I like the simplification with the
> > removal of the wild section.
> > 
> > One comment,
> > 
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> > 
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
> > existing NSEC3 records on the zone.
> > 
> > 
> > One clarification question,
> > 
> > At 3.6, last paragraph, what is the practical case that a updated
> > record has an RDLENGTH of zero bytes?
> > 
> >> Who would like to contribute, review, and all that great fun?
> >> 
> >> Github is here: https://github.com/matje/mixfr
> >> 
> >> Best regards,
> >>   Matthijs
> > 
> > Fred
> > 
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>