IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Fri, 24 August 2018 07:26 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 005B0130DD9 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:26:32 -0700 (PDT)
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 zbNTWp8hzu2Q for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 00:26:30 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 4D0E61292AD for <dnsop@ietf.org>; Fri, 24 Aug 2018 00:26:30 -0700 (PDT)
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 184CE3AB004; Fri, 24 Aug 2018 07:26:30 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 002AC160044; Fri, 24 Aug 2018 07:26:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E016216005B; Fri, 24 Aug 2018 07:26:29 +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 HU3vY1KJDNwZ; Fri, 24 Aug 2018 07:26:29 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E2F50160044; Fri, 24 Aug 2018 07:26:28 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <5B7FB012.6000607@redbarn.org>
Date: Fri, 24 Aug 2018 17:26:25 +1000
Cc: Tom Pusateri <pusateri@bangj.com>, Tim Wattenberg <mail@timwattenberg.de>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <20790AA8-3429-4FB3-862E-7049C53AF264@isc.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>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/R8K9jVBNDGXW7kFgwX9cQeb4Vno>
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:26:32 -0000


> On 24 Aug 2018, at 5:13 pm, Paul Vixie <paul@redbarn.org> wrote:
> 
> 
> 
> 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.

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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email