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

Joe Abley <jabley@hopcount.ca> Thu, 21 February 2019 22:52 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 5931B131288 for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 14:52:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] 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 KCHf51801NYU for <dnsop@ietfa.amsl.com>; Thu, 21 Feb 2019 14:52:57 -0800 (PST)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 231EA1312AC for <dnsop@ietf.org>; Thu, 21 Feb 2019 14:52:57 -0800 (PST)
Received: by mail-it1-x134.google.com with SMTP id l66so465521itg.3 for <dnsop@ietf.org>; Thu, 21 Feb 2019 14:52:57 -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=iaPJwHi/8/+zkKIKAKvwQIpgTqW4zOc1wQoyjft5X4s=; b=ADWbMjVVGTSGTVTx3P2BAV+mTHL2vVKm6sqku9c0WKxrqJXl8K8nVr5/dS8N37KPPG Y47zOUqhXDYsi3fYb28ei+i5JpUV2606jg9LBy3v4dgynFO1UMyUtCStslmsiT/yobsT h0PigpQ7mv5gCftE8LVOz4lWWhSxM31CqMZWI=
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=iaPJwHi/8/+zkKIKAKvwQIpgTqW4zOc1wQoyjft5X4s=; b=PV74gfXMjtSzK5XMAYZKg4sUSNM2CUGnbbhrotUN6Ttyb+yDPZMNQE35ZgHz1ciN2p TT63xolEV7oitr7sErR+aXEKitXxawy6rI9KQ4Uba27a7icyUwjft3YkVovEu2e3+FYN uTOujWjXFriRvROa/DWWrNWLtzseoyyQqWjfGxgXfPODgB80qB6Sgws3t+gvPTz3UuKW X7d9kfWi6nJWq/vH7lxtcJjg5D8al69ThldZ7e78FcZ3HmmhWOYvNi+NhNnhePvAi8zq ilPSCW8EH3ADnUscchzOvlmtNgM9k0hqUdP+09PsVczwog1SaV3qSwmsU8/G5nsopk3Y j5Ig==
X-Gm-Message-State: AHQUAuYycy1v4N8IFPFOsAONY4V7XgUHPmWhO8ZZi1TmXI32AMYx6TXc CAJcStHW2L+gFVwhbP1XhUl8Aw==
X-Google-Smtp-Source: AHgI3IZJHrqLAQV2ZmdROEd+p9rujz8M0XXBQPNGSJ+ji0Fxe5RDys5QLcueuMh2xg7IwMHIufMaxA==
X-Received: by 2002:a02:4f1c:: with SMTP id c28mr645507jab.112.1550789576152; Thu, 21 Feb 2019 14:52:56 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:fd79:3639:7779:cf32? ([2607:f2c0:101:3:fd79:3639:7779:cf32]) by smtp.gmail.com with ESMTPSA id h8sm116396ith.2.2019.02.21.14.52.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 14:52:54 -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: <FC8037A8-37E2-4457-A410-6CECBB709D49@isc.org>
Date: Thu, 21 Feb 2019 17:52:50 -0500
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: <7B435A7E-0418-4451-AC12-6ED21F8FCCD2@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> <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca> <CAJE_bqd3cAqtv_FkvhuCC6jubzZLx9v5ud2WzrL9bQE+8tLB8w@mail.gmail.com> <FC8037A8-37E2-4457-A410-6CECBB709D49@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v26W8U7Px0P3ZJI9uHJpfEBJ7BA>
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 22:52:59 -0000

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? 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?

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?

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.


Joe