Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Benno Overeinder <benno@NLnetLabs.nl> Sun, 24 March 2019 11:03 UTC

Return-Path: <benno@NLnetLabs.nl>
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 66CE81286E7 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 04:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 Ez0aQeXn0r1a for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 04:03:34 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 D03D2127961 for <dnsop@ietf.org>; Sun, 24 Mar 2019 04:03:33 -0700 (PDT)
Received: from dhcp-916c.meeting.ietf.org (unknown [IPv6:2001:67c:1232:144:a4cd:959:b61b:3552]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0F196A49D for <dnsop@ietf.org>; Sun, 24 Mar 2019 12:03:31 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=NLnetLabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=benno@NLnetLabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1553425411; bh=Dn+bxZ9wnRvFT/WYtBJ3idfCWSfaH4Nkkjvbvr7vi98=; h=Subject:To:References:From:Date:In-Reply-To; b=O3pkSayaRlMVZ7oZ8x/uXIIDK1c8f3MnEzYOJ7TyKLL99hlZ0RyNlGuwp7he0KRzL E4yz+uaGPHmbTNGF+/ppLoYLq1+mEIAJQy9f7h8Z7AYrupwZDfKrTBVQXRraz43YxF 99r6VXVgAlR4Up8PCgsrO9Y6HtcYrFLE7lglkLg0=
To: dnsop@ietf.org
References: <CAJE_bqdugE3oMqyHres4hwhs4-NpO8yW2FwGDrk2WDAtbweBiQ@mail.gmail.com> <23682.53436.400539.805166@gro.dd.org>
From: Benno Overeinder <benno@NLnetLabs.nl>
Openpgp: preference=signencrypt
Message-ID: <8ffa4b04-324a-36c8-a9ff-e0cda726a54c@NLnetLabs.nl>
Date: Sun, 24 Mar 2019 12:03:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <23682.53436.400539.805166@gro.dd.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EJXpeBI9YL_PQEgY1j1MCKMhyN0>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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: Sun, 24 Mar 2019 11:03:35 -0000

Hi,

On 08/03/2019 21:29, Dave Lawrence wrote:

> Huh, My understanding from a hallway conversation with Benno was that
> the immediate response is only sent for names that would have been
> subject to pre-fetching, such that the immediate response in this case
> is sufficiently covered under the guidance of a recent attempt being
> made.  If that is not the case, and you can get stale answers from
> Unbound even without a recent refresh attempt, then I personally think
> that is an error in Unbound and not this document.

The current implementation of serve stale in Unbound is closely related
with the pre-fetching process.  It works well for most cases, that is
names that are frequently queried for, so the pre-fetch assures for
fresh and correct entries in the cache.

For names with relative short TTLs and that are not frequently queried
for (i.e. less frequent than covered by the TTL), the entry from the
cache is stale and only after serving the reply, a pre-fetch (resolve)
is initiated to update/re-fresh the entry in the cache.

We acknowledge this behavior is not optimal in some situations and will
reimplement a part of the re-fresh strategy of cache entries.

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/