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

Mark Andrews <marka@isc.org> Thu, 21 February 2019 23:22 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 0D4FD1312A9 for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 15:22:39 -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 DJprVODSaVP8 for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 15:22:37 -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 1AC5D1312E9 for <dnsop@ietf.org>; Thu, 21 Feb 2019 15:22:37 -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 A6D073AB05E; Thu, 21 Feb 2019 23:22:36 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6FAB1160074; Thu, 21 Feb 2019 23:22:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 41294160073; Thu, 21 Feb 2019 23:22:36 +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 iVbfBUMfPp6g; Thu, 21 Feb 2019 23:22:36 +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 3AE8D160050; Thu, 21 Feb 2019 23:22:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <7B435A7E-0418-4451-AC12-6ED21F8FCCD2@hopcount.ca>
Date: Fri, 22 Feb 2019 10:22:32 +1100
Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <89BFB2B7-3804-46D7-8D25-D3595CABC827@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> <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org> <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca> <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca> <CAJE_bqd3cAqtv_FkvhuCC6jubzZLx9v5ud2WzrL9bQE+8tLB8w@mail.gmail.com> <FC8037A8-37E2-4457-A410-6CECBB709D49@isc.org> <7B435A7E-0418-4451-AC12-6ED21F8FCCD2@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CDX5zA9b718rl6ZbsD5qjT_x_2g>
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: Thu, 21 Feb 2019 23:22:43 -0000


> On 22 Feb 2019, at 9:52 am, Joe Abley <jabley@hopcount.ca> wrote:
> 
> On 21 Feb 2019, at 14:34, Mark Andrews <marka@isc.org> wrote:
> 
>> Machines die. Machines are unplugged.  Server are unreachable at critical times. Externally driven cleanup can never be reliable. 
> 
> I'm not disputing any of that. I guess my first question was first whether cleanup is necessary, and second (assuming it is) whether cleanup can't just be handled as an implementation detail as opposed to a protocol extension.
> 
> If the master server that receive UPDATEs matching particular names could be configured to remove them after a suitable interval, wouldn't that do the trick?

No.  How do you make “permanent” changes to the zone using UPDATE?

> Slave servers would get new copies of the zones concerned following the updates in the normal manner. Zone propagation is pretty swift with NOTIFY. The master could apply policy based on criteria like owner name pattern matching or source of the update. Garbage collection might not happen with the kind of split-second accuracy that I sense this mechanism's proponents are suggesting, but does it need to? Don't we believe that applications that expect more than loose coherence from the DNS are broken?

Nothing in this draft changes loose coherence.  Everything is done by the master.  The slave has the data so it has the state to become the master when the machine that was the master dies.

> I hear and acknowledge there is a desire for this kind functionality (i.e. I believe you that it's necessary) but I'm still not clear on what need there is for interoperability (and hence standardisation). Every DNS implementation contains their own special features that are not standardised and that don't need to be. Couldn't this be another one?

No.  There are plenty of our customers that want features to work cross platform.  They also want to be able to switch to a different code base when there is a security issue in another one.  They also want things to work as well as possible for disaster recovery.  Having the GC information is a vendor neutral form achieves these objectives.

There are plenty of customers where all the slaves are transferring data from two masters all the time.  Those masters are from different vendors with transfers flowing from which ever is currently configured as the ultimate master between them.  The may also be configured to transfer from all of the slaves as well.  If current master dies / is taken out of service the backup master will get the newest copy of the zone that has made it to any of the other servers within minutes.  It can then be reconfigured as the active master and continue straight away.  Throwing proprietary GC into this does not work.

> I remain open to the idea that I am just missing the point because I don't spend enough time in enterprise or campus networks. I think I'm possibly not the only one in that boat, though, and I don't think it's unreasonable for the draft to explore its applicability and explain clearly why standardisation or in-zone signalling (hence RRs) is necessary as a prerequisite to standardisation. As I mentioned before, the bar for experimental is surely much lower, and the bar for simple codepoint assignment lower still.

What are the terms of the experiment if you want experimental?  What are you wanting to discover?  That the protocol works?

> Joe

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