Re: [DNSOP] A new version of mixfr

Frederico A C Neves <> Thu, 29 March 2018 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B81AE12E037 for <>; Thu, 29 Mar 2018 11:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8x1wHyXVuAN for <>; Thu, 29 Mar 2018 11:17:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FF2212DFDB for <>; Thu, 29 Mar 2018 11:17:27 -0700 (PDT)
Received: by (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 <>
To: Mark Andrews <>
Cc: Matthijs Mekking <>,
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] A new version of mixfr
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>; 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.