Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Tom Pusateri <pusateri@bangj.com> Sat, 25 August 2018 03:55 UTC

Return-Path: <pusateri@bangj.com>
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 6EB3F130DE0 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 20:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 8BirVSZnRvio for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 20:55:31 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FFB130DC1 for <dnsop@ietf.org>; Fri, 24 Aug 2018 20:55:31 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1F82820A6; Fri, 24 Aug 2018 23:51:14 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <51A00DE1-0418-4404-B583-246E20BE17F2@isc.org>
Date: Fri, 24 Aug 2018 23:55:27 -0400
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DBC5AA8-5DA6-4F48-9AFB-970C7BE61D72@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <51A00DE1-0418-4404-B583-246E20BE17F2@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m-1unKwXK1pW4ozpqYaXgEkCjmQ>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 25 Aug 2018 03:55:34 -0000


> On Aug 24, 2018, at 3:46 AM, Mark Andrews <marka@isc.org> wrote:
> 
> This is unnecessary.  All the rule does is limit the process to class IN zones.  UPDATE, IXFR and AXFR are class agnostic.
> 
> 1.  TIMEOUT resource records are only defined for CLASS IN.

Ok, we will make them applicable to all classes.

> 
> This seems overly restrictive.  I would allow TIMEOUT records that
> match added records to be accepted.
> 
> 5.  TIMEOUT resource records cannot be directly added, modified, or
>       deleted through DNS Update.

This restriction is another consequence of not being able to query TIMEOUT records. In order to allow UPDATE of TIMEOUT records, the client has to be able to retrieve the record and merge changes before UPDATING it. The server can’t do the merging or the record would change underneath the client that created it when another client added a record with the same owner name.

We haven’t been able to think of any significant downsides to allowing QUERY of TIMEOUT records and by doing so, it solves Joe’s issues so unless you can think of any, we’ll make that change in the next version and then be able to support UPDATE of TIMEOUT records.

> 
> Secondary servers that are TIMEOUT aware should ignore TIMEOUT records
> beyond storing them in case the server get promoted to being the master.
> 
> Is the secondary going to be able regenerate the RRset as the records are
> removed as well as generate and sign NSEC and NSEC3 records?

I would expect a secondary server to treat them the same as it does any other record type.

> 
> Sources of TIMEOUT Expiry Time
> 
> Add matching TIMEOUT records added via UPDATE.

Ok.

Thanks!

Tom