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

Dave Lawrence <tale@dd.org> Fri, 01 March 2019 17:33 UTC

Return-Path: <tale@dd.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 0ED4D130EB4 for <dnsop@ietfa.amsl.com>; Fri, 1 Mar 2019 09:33:18 -0800 (PST)
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 lskw2AkLSGSd for <dnsop@ietfa.amsl.com>; Fri, 1 Mar 2019 09:33:16 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991FB130EA5 for <dnsop@ietf.org>; Fri, 1 Mar 2019 09:33:15 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 0CDAC1B27C; Fri, 1 Mar 2019 12:33:14 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23673.27866.35423.674591@gro.dd.org>
Date: Fri, 1 Mar 2019 12:33:14 -0500
From: Dave Lawrence <tale@dd.org>
To: IETF DNSOP WG <dnsop@ietf.org>
In-Reply-To: <CA+nkc8DvZr84E46vna91iBsJ2uSVsda1cCzyTNx9C_J85uKW1w@mail.gmail.com>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+nkc8DvZr84E46vna91iBsJ2uSVsda1cCzyTNx9C_J85uKW1w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4cKpxiqEvgrWPlQDW9k1S1liwtg>
Subject: Re: [DNSOP] 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:33:18 -0000

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.