Re: [DNSOP] draft-tale-dnsop-serve-stale

Robert Edmonds <edmonds@mycre.ws> Mon, 27 March 2017 22:47 UTC

Return-Path: <edmonds@mycre.ws>
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 4848B129577 for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 FMOOgSiTB_Dl for <dnsop@ietfa.amsl.com>; Mon, 27 Mar 2017 15:46:59 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27532126E3A for <dnsop@ietf.org>; Mon, 27 Mar 2017 15:46:55 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 93E7F12C10F2; Mon, 27 Mar 2017 18:46:54 -0400 (EDT)
Date: Mon, 27 Mar 2017 18:46:54 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: Jared Mauch <jared@puck.nether.net>
Cc: paul vixie <paul@redbarn.org>, dnsop@ietf.org, Dave Lawrence <tale@dd.org>
Message-ID: <20170327224654.uaijxchvqhdgxb4m@mycre.ws>
References: <22745.35498.811412.936974@gro.dd.org> <69EA837B-77BE-4202-8BFF-0243CF6AAC07@redbarn.org> <B18C12F9-D3EF-46D7-90D4-E58CEA575966@puck.nether.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B18C12F9-D3EF-46D7-90D4-E58CEA575966@puck.nether.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DF3KynBqGFtTbz003AHA7ZVxQ20>
Subject: Re: [DNSOP] draft-tale-dnsop-serve-stale
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 27 Mar 2017 22:47:01 -0000

Jared Mauch wrote:
> IOn Mar 27, 2017, at 5:59 PM, P Vix <paul@redbarn.org> wrote:
> > 
> > I agree to review and comment. Note that I am provisionally negative to the idea itself, and my review may reflect that. Vixie
> 
> 
> I will note there are other implementations out there as well, such as in unbound.  serve-expired configuration directive is available there as well.

Though, the algorithm described in this document is a much different
algorithm than the one in Unbound.

If I understand Unbound's serve-expired algorithm correctly, it always
serves from cache if available (regardless of expiration status), and if
what it served to the client happened to be expired, it triggers a
post-response fetch to update the cache asynchronously. That can end up
serving a lot more stale bread than is strictly necessary if your
Unbound server only serves a few clients.

(I guess Unbound could sort of be said to implement this draft, but with
the client response timer hardcoded to 0 and the maximum stale timer
hardcoded to ∞.)

I support adoption of this document.

-- 
Robert Edmonds