Re: [DNSOP] A new version of mixfr

Matthijs Mekking <matthijs@pletterpet.nl> Wed, 28 March 2018 15:43 UTC

Return-Path: <matthijs@pletterpet.nl>
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 561B9127369 for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 08:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 3Fty8QlHoKqj for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 08:43:19 -0700 (PDT)
Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 1C02C120047 for <dnsop@ietf.org>; Wed, 28 Mar 2018 08:43:18 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:a104:4f71:de86:2e0] ([IPv6:2001:981:19be:1:a104:4f71:de86:2e0]) by smtp-cloud8.xs4all.net with ESMTPSA id 1DEJfMbOK4EsM1DELfI8Nu; Wed, 28 Mar 2018 17:43:17 +0200
To: Frederico A C Neves <fneves@registro.br>
Cc: dnsop@ietf.org
References: <d7c4fc25-9d4b-d934-bad3-61e7b8364ca2@pletterpet.nl> <20180328150651.GQ62218@registro.br>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <da942f70-c822-81c3-3355-d6f453b8ee6c@pletterpet.nl>
Date: Wed, 28 Mar 2018 17:43:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180328150651.GQ62218@registro.br>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfH9NUgVNodT5iEiarr5TnhBu6M2yUwlonQUiVYUw2zxKCTJcjGApgckS+zMhzO8rqS8x1oCCu1I9OPnUxm3hOyt+8l7nnDmbosIu7YiyshwVfb18V5EO gYyqZXoJoBqksMbCjjyesKv+kAYdP3hXvr2Ce6B6OiR8llVVdxjj7YXUIKO7ioQhenBIgSI3A4iBMMxZU3bxhoZRsXvL5vqMB6jKYSteofLClvRb4YXKMBdF cvzoC0dWVAQpeETNb06J3/gq0DmhEZwvWv8/7PkrfTdyw1go+NIsSrs+Q3yYilnT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hSmkWvHF7hBbVBq01pWRG58W5EY>
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 15:43:21 -0000

Frederico,

On 03/28/2018 05:06 PM, Frederico A C Neves 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.

Thank you.


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

I agree that with the current syntax NSEC3 resalting is still a hassle. 
But I am not sure if this implicit NSEC3 deletion is the right solution: 
One can have multiple chains in the zone, the NSEC3PARAM just signals 
that the chain is complete. Signers may have incomplete chains as an 
intermediate step of NSEC3 resalting.

I shall add a GitHub issue for this. Thanks for bringing it up!


> One clarification question,
> 
> At 3.6, last paragraph, what is the practical case that a updated
> record has an RDLENGTH of zero bytes?

It is as Richard pointed out not required, but I would like to clarify 
the difference between deleting an RRset and replacing an RRset.

Best regards,

Matthijs


>   
>> Who would like to contribute, review, and all that great fun?
>>
>> Github is here: https://github.com/matje/mixfr
>>
>> Best regards,
>>     Matthijs
> 
> Fred
>