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

Paul Vixie <paul@redbarn.org> Fri, 24 August 2018 07:13 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 D16EA130DE2 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:13:29 -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, 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 hYvAkH9VFgPm for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:13:26 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E924C129619 for <dnsop@ietf.org>; Fri, 24 Aug 2018 00:13:26 -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 CDC51892C6; Fri, 24 Aug 2018 07:13:24 +0000 (UTC)
Message-ID: <5B7FB012.6000607@redbarn.org>
Date: Fri, 24 Aug 2018 00:13:22 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Tom Pusateri <pusateri@bangj.com>, Tim Wattenberg <mail@timwattenberg.de>
CC: 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>
In-Reply-To: <45A6E3AE-16C2-4A77-9B57-C76DAA8C972A@bangj.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DlhXcBnNLNV4HqhumT-gBZj_H2k>
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:13:30 -0000


Tom Pusateri wrote:
> I don’t think there is a TTL issue because, as we proposed it, the
> record is never returned in a query. The TTL could always be set to 0
> for our purposes since it never leaves the authoritative servers.

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.

in <http://family.redbarn.org/~vixie/defupd.txt> from 1996, this is 
described as follows:

> 3.4.1 - Initial TTL Limits
>
>    The TTL of all added or updated RRs in the Update Section will be
>    maximized silently to one half of the Expiry time.  This will cause
>    downstream caching name servers to purge RRsets containing this RR at
>    least once before expiry.
>
> 3.4.2 - TTL Half Life
>
>    Each time an RR's expiry reaches half of its previous value, that RR's
>    TTL will be reduced to half of its previous value, until the TTL reaches
>    a value less than or equal to sixty (60), i.e., one minute of real time,
>    at which time the TTL will not be automatically reduced further by the
>    primary master.  It should be noted that RRs held in a server's memory
>    need not be swept for half life processing, as long as the TTL changes
>    appear when the RR next becomes externally visible, and as long as the
>    ``zone has changed'' processing (see below) is done at the time of the
>    half life expiration.
>
>    Whenever the TTL is automatically reduced by this process, the zone will
>    be considered ``changed'' for the purpose of automatic SOA SERIAL
>    increment (see [UPDATE 3.6]) and real time zone slave notification (see
>    [NOTIFY]).

-- 
P Vixie