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

Mark Andrews <marka@isc.org> Wed, 20 February 2019 19:16 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 9670F130E58 for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 11:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 zIaDNKkzec1q for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 11:15:58 -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 5B274130E57 for <dnsop@ietf.org>; Wed, 20 Feb 2019 11:15:57 -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 323383AB060; Wed, 20 Feb 2019 19:15:56 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 00A9316005B; Wed, 20 Feb 2019 19:15:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D070B160070; Wed, 20 Feb 2019 19:15:55 +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 1be15h0WSjhU; Wed, 20 Feb 2019 19:15:55 +0000 (UTC)
Received: from [172.30.42.88] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 55B1A16005B; Wed, 20 Feb 2019 19:15:55 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca>
Date: Thu, 21 Feb 2019 06:15:52 +1100
Cc: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E41DDEED-DF50-481F-9378-D721C3612643@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>
To: Joe Abley <jabley@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1yr0Zh78BqxTPktPHZDDCRTCpPE>
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: Wed, 20 Feb 2019 19:16:00 -0000

Joe, look at active directory. The names in the DNS are garbage cleaned by undocumented processes that prevent UPDATE being used to manage the “static” content. 

You have registering AAAA and PTR records with SLAAC. You don’t want stale records to continue to exist in the zones. You will be sent to the wrong machine (AAAA) or the zone will become a garbage dump of stale records (PTR).   But until the support is there you can’t safely do this. 

Today you can use SIG(0) to register your AAAA records and use TCP to authenticate PTR  additions to the DNS zones. All that is missing is the automated cleanup.  DNS servers are quite capable of doing that once specified how.   DHCP servers mostly do this for IPv4 but even that is problematic.  Records still get left behind because there was a communication failure at lease expiry / release. 

DNS-SD has the same issues. Garbage collection. 

You also need it as standards track so people won’t think it is something that is going away and to encourage everyone who implements UPDATE to support it.  Clients and servers. 
-- 
Mark Andrews

> On 20 Feb 2019, at 23:51, Joe Abley <jabley@hopcount.ca> wrote:
> 
>> On 20 Feb 2019, at 00:35, Paul Wouters <paul@nohats.ca> wrote:
>> 
>>> On Wed, 20 Feb 2019, Mark Andrews wrote:
>>> 
>>> 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.
>> 
>> That is not very convincing to me. disaster recovery scenarios seem to
>> be solvable by proper admin and by the daemon properly writing state to
>> disk which can be saved off-site. It also seems a rather rare occurance.
> 
> I agree.
> 
> The crux of the use case seems to be that it is commonplace for names in the DNS to exist for short periods of time and that for some applications a name that overstays its welcome can cause an operational problem.
> 
> While I can understand the philosophical desire to complete the UPDATE specification so that it is possible to engineer around this scenario, I don't see the practical application. The existence of the requirement in the first place seems unproven (at least there are no obvious examples given); the scenario in which the purported operational problem arises seems likely to be rare; workarounds surely exist and, really, the damage in the event that the stars align and a temporary name does persist seems very low.
> 
> If the goal is to try this out and have no impact on existing implementations (e.g. there is some side code that is imagined that will poll a transferred zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that should not be there) then all that is really needed here is a code point for the TIMEOUT RR. The existence of the draft is nice since documentation is good, but I think "experimental" would be a better target than "standards track". It's surely possible that this mechanism will solve some as-yet unnoticed, large-scale problem and will one day be considered essential functionality, but I don't think we're there today. There be camels.
> 
> 
> Joe
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop