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

Joe Abley <jabley@hopcount.ca> Wed, 20 February 2019 12:51 UTC

Return-Path: <jabley@hopcount.ca>
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 85A471286E7 for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 04:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 ckSSjAQ6oIKa for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 04:51:55 -0800 (PST)
Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D321279E6 for <dnsop@ietf.org>; Wed, 20 Feb 2019 04:51:55 -0800 (PST)
Received: by mail-it1-x142.google.com with SMTP id r11so14904446itc.2 for <dnsop@ietf.org>; Wed, 20 Feb 2019 04:51:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YDKToZHsyn88/LFV0fmAzmG48MneP4rkhKqjmolPidU=; b=RvY7vGaEyNM9pUD4IE/rVYuXoVRzYZ614tWtZ8AEGnzwAwC2vEMwRy/CskEuiF5QKs IJV1hOgTz5Vg9ASbXjAqaHJ0+0x1zgTFsMvLA+85/s9zYVfzFleCtisrYHvNq/X8XK3e WiO8gOe2e2EcaBO6vOKiyRvAjFuKgQKApB1eA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YDKToZHsyn88/LFV0fmAzmG48MneP4rkhKqjmolPidU=; b=Hbp62Y4OFoMwjVCdA2lMD4FxihVAs3DYB125omxlz/k3OuUpjtfNSDIVY7SinHo0CU CpIH6PYwV4dNyDw+wI/k2deXhHQL8aEbZBkVbzw4wOjddJqngxEtyOgdJjkSAxbAK4yz kHCdLXfcMqhiASBsp0t1HVvnyqGIBTHrWvgI8uTWRWilTVd/NHN1raWnrijz/MJgPI31 vuMUcBVEThlvwxWZBNJroAVsSeTc08ps4RiRHDY0ICgdyum9YJVqkz70P2F1YuoFRgpn Vdvp2vWcv4gWYG/Xi9EZD4md4CGeXZ239XOiplNQEMnUKlboTi+JQ/t/vHmBEhM0yCHW sMIQ==
X-Gm-Message-State: AHQUAuZUIUMCWkq8pR9lTsrjS3sZA73GEfR7F73wB6uLmxjWTAdQ8Gg8 Bs98/QgtY3IvDh60YoOfZ8ZyMA==
X-Google-Smtp-Source: AHgI3IZORJpR1snKCUTLzxu6LVtzj4JaK5w2Ks+fTRPkD3Vrn9QmDbPB3/I8tTzGqLBlYw+90y/9og==
X-Received: by 2002:a02:5618:: with SMTP id o24mr19313758jab.111.1550667114562; Wed, 20 Feb 2019 04:51:54 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:3457:4bda:1165:ab63? ([2607:f2c0:101:3:3457:4bda:1165:ab63]) by smtp.gmail.com with ESMTPSA id e5sm8202706ios.50.2019.02.20.04.51.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 04:51:53 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca>
Date: Wed, 20 Feb 2019 07:51:51 -0500
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca>
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>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0wqpKGk-rusM2WRiS-_BEw3exVk>
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 12:51:58 -0000

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