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

Mark Andrews <marka@isc.org> Tue, 19 February 2019 22: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 42088130FFF for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 14:36:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZoviQlAdB0Od for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 14:36:46 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 F3C1C130FF0 for <dnsop@ietf.org>; Tue, 19 Feb 2019 14:36:45 -0800 (PST)
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 3C2D03AB05B; Tue, 19 Feb 2019 22:36:45 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0DDF016005C; Tue, 19 Feb 2019 22:36:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D0693160067; Tue, 19 Feb 2019 22:36:44 +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 WuRvzMKT3LVz; Tue, 19 Feb 2019 22:36:44 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 348A116005C; Tue, 19 Feb 2019 22:36:44 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca>
Date: Wed, 20 Feb 2019 09:36:41 +1100
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org>
References: <155053239541.25848.12960190085730298684.idtracker@ietfa.amsl.com> <969D8BA1-6ED3-47E8-AFFD-2BEE8EA3E66B@bangj.com> <alpine.DEB.2.20.1902191219070.766@grey.csi.cam.ac.uk> <0DE33073-93B1-4CF5-B12D-B7266E21E8B2@timwattenberg.de> <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Enc8cVzwVxRYjibcFMLso1Pk6HU>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 19 Feb 2019 22:36:48 -0000

Think disaster recovery and promoting a slave to master.  You have to
transfer state between servers.  You can transfer it in band or out of
band.  If you transfer it out of band you need to invent / specify
yet-another-protocol to do it on top of specifying when records need to
be removed.

Mark

> On 20 Feb 2019, at 9:26 am, Paul Wouters <paul@nohats.ca> wrote:
> 
> 
> I have read the document.
> 
> I have a question about:
> 
>   A zone administrator may
>   want to enforce a default lifetime for dynamic updates (such as the
>   DHCP lease lifetime) or the DNS Update may contain a lifetime using
>   an EDNS(0) Update Lease option [I-D.sekar-dns-ul].
> 
> This seems a local policy and local implementation issue only.
> 
>  However, this
>  lease lifetime is not communicated to secondary servers and will not
>  endure through server software restarts.
> 
> Why does the secondary server need to know the lease lifetime? Only the
> primary needs to know this because it will need to purge the records and
> update the appropriate DNSSEC entries, something the secondary cannot do
> anyway? In fact, Section 8 agrees with me:
> 
>   A secondary server MUST NOT expire the records in a zone it maintains
>   covered by the TIMEOUT resource record and it MUST NOT expire the
>   TIMEOUT resource record itself when the last record it covers has
>   expired.  The secondary server MUST always wait for the records to be
>   removed or updated by the primary server.
> 
> So why is the TIMEOUT record needed? If the secondary argument is
> gone, the only argument left from the Introduction is server software
> restart. Which seems to me to be an application issue and not a protocol
> issue?
> 
> As others pointed out, introducing SHA3 into the DNS right now is not
> appropriate.
> 
> I see a use for clients telling the dns update server what the maximum
> possibly lifetime can be, so it can go and perform a delete request on
> behalf of vanished clients. But again I don't see this as a protocol
> issue needing a TIMEOUT RRTYPE ?
> 
> Did I miss anything?
> 
> Paul
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org