Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Paul Hoffman <paul.hoffman@icann.org> Fri, 01 March 2019 17:50 UTC

Return-Path: <paul.hoffman@icann.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 174F0130E82 for <dnsop@ietfa.amsl.com>; Fri, 1 Mar 2019 09:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 0jWbEXYQp5Aa for <dnsop@ietfa.amsl.com>; Fri, 1 Mar 2019 09:50:56 -0800 (PST)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2530A12008A for <dnsop@ietf.org>; Fri, 1 Mar 2019 09:50:52 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 1 Mar 2019 09:50:50 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Fri, 1 Mar 2019 09:50:50 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: David Lawrence <tale@dd.org>
CC: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Thread-Index: AQHU0FdOlsD2kphP5U2DWYYiL/jxFA==
Date: Fri, 1 Mar 2019 17:50:49 +0000
Message-ID: <FD2C124D-BD1E-41AE-B4AB-007E451A32D6@icann.org>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+nkc8DvZr84E46vna91iBsJ2uSVsda1cCzyTNx9C_J85uKW1w@mail.gmail.com> <23673.27866.35423.674591@gro.dd.org>
In-Reply-To: <23673.27866.35423.674591@gro.dd.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C947BA7A0CB5A1478C25EABFCB154C57@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wGbYG1fH9qffu-B6_F9JhWGLHuY>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.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: Fri, 01 Mar 2019 17:50:59 -0000

On Mar 1, 2019, at 9:33 AM, Dave Lawrence <tale@dd.org> wrote:
> 
> Bob Harold writes:
>> Will the "resolution recheck timer" cause ttl's less than the timer
>> to be effectively lengthened, by refusing to look them up again?  I
>> think 'serve-stale' should focus on the situation where the auth
>> server is not available, and not change the handling of short ttl's.
>> Or am I mis-reading that?
> 
> Mildly misreading, though it does point out that we could make it
> clearer that this is akin to existing mechanisms that resolvers have
> to cache that an authority is problematic (eg, RFC 2308 Section 7).
> It is NOT about the feature that some resolvers also have, a minimum
> cache TTL, which is what you're concerned about and we don't intend to
> address in this document.  As you say, and unfortunately we somehow
> managed to not make clear, the purpose is only to deal with failures
> to refresh authoritative data.

FWIW, I read it like Bob did. The following paragraph from the current draft makes it clear that the draft is proposing that the resolution recheck timer be lengthened to at least 30 seconds.

   If iterative lookups will be, done then the resolution recheck timer
   is consulted.  Attempts to refresh from the authorities are
   recommended to be done no more frequently than every 30 seconds.  If
   this request was received within this period, the cache may be
   immediately consulted for stale data to satisfy the request.

I'm not sure a standards track document that updates RFC 1034/1035 should be recommending a minimum TTL.

--Paul Hoffman