IETF Logo Mail Archive

Re: [DNSOP] A new version of mixfr

Mark Andrews <marka@isc.org> Wed, 28 March 2018 23:36 UTC

Return-Path: <marka@isc.org>
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 E4FD91242F5 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 16:36:17 -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 HOYHrhgt1sn8 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 16:36:16 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 51DF71200FC for <dnsop@ietf.org>; Wed, 28 Mar 2018 16:36:16 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2AB383AB078; Wed, 28 Mar 2018 23:36:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 021DF160053; Wed, 28 Mar 2018 23:36:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DA2C4160077; Wed, 28 Mar 2018 23:36:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5faX52C7ekoq; Wed, 28 Mar 2018 23:36:15 +0000 (UTC)
Received: from [172.30.42.91] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0A9CC160053; Wed, 28 Mar 2018 23:36:14 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20180328220510.GB94914@registro.br>
Date: Thu, 29 Mar 2018 10:36:12 +1100
Cc: Matthijs Mekking <matthijs@pletterpet.nl>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A790C5A6-560B-4B72-9049-84E57982A7EF@isc.org>
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>
To: Frederico A C Neves <fneves@registro.br>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/owfdQjzR5A-siu3dTlKVJuGAPq0>
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 23:36:18 -0000

> 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.

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: marka@isc.org

v2.23.0 | Report a Bug | By Email