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

Paul Vixie <paul@redbarn.org> Fri, 24 August 2018 07:38 UTC

Return-Path: <paul@redbarn.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 EEC6E130DE2 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 sw_6k0j-Bqjr for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:38:53 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0AA1130934 for <dnsop@ietf.org>; Fri, 24 Aug 2018 00:38:53 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6F0DA892C6; Fri, 24 Aug 2018 07:38:53 +0000 (UTC)
Message-ID: <5B7FB60B.60400@redbarn.org>
Date: Fri, 24 Aug 2018 00:38:51 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
CC: Tom Pusateri <pusateri@bangj.com>, Tim Wattenberg <mail@timwattenberg.de>, dnsop WG <dnsop@ietf.org>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <45A6E3AE-16C2-4A77-9B57-C76DAA8C972A@bangj.com> <5B7FB012.6000607@redbarn.org> <20790AA8-3429-4FB3-862E-7049C53AF264@isc.org>
In-Reply-To: <20790AA8-3429-4FB3-862E-7049C53AF264@isc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CF45OjLJY3T4bHqICAtAId6ANpo>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 24 Aug 2018 07:38:55 -0000


Mark Andrews wrote:
>
>> On 24 Aug 2018, at 5:13 pm, Paul Vixie<paul@redbarn.org>;  wrote:
...
>> tom, (tim,) to be clear, the ttl which must decline is that of the
>> expiring record (or its rrset, due to atomicity), and not that of
>> the TIMEOUT RR itself. you cannot hand out an AAAA or PTR (or in
>> the degenerate case, an A RR) with a TTL of 3600 if it is due to
>> expire in 600 seconds. that RR has to have its TTL adjusted during
>> its final authority-TTL interval so that noone has it in cache
>> beyond the time of its death by expiry.
>
> That’s one way of doing it.  Given the DNS is loosely coherent I
> really would just leave it as the time the record is removed from the
> zone and not play TTL games which require every server for the zone
> to support the extension.  If you are worried about records being in
> the cache too long use a smaller TTL from the start.

that may be nec'y given that this is not a deferred update mechanism, 
which is what led in 1996 to the half-life auto-update for propagation.

however, every authority server MUST support the TIMEOUT RR as proposed 
-- that's why i proposed that the configuration for it be negotiated via 
OPT rather than statically configured as proposed. so, every such server 
can have tickdown logic to avoid the bad choice between too-short TTL 
and too-stale data.

-- 
P Vixie