IETF Logo Mail Archive

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

Holger Freyther <dnsop@freyther.de> Mon, 04 March 2019 06:19 UTC

Return-Path: <dnsop@freyther.de>
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 857A4130FC5 for <dnsop@ietfa.amsl.com>; Sun, 3 Mar 2019 22:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MgAo_55THUpi for <dnsop@ietfa.amsl.com>; Sun, 3 Mar 2019 22:19:13 -0800 (PST)
Received: from gandharva.secretlabs.de (gandharva.secretlabs.de [IPv6:2a01:4f8:161:8201::2:4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28EB131006 for <dnsop@ietf.org>; Sun, 3 Mar 2019 22:19:12 -0800 (PST)
Received: from [10.0.1.2] (1-36-234-068.static.netvigator.com [1.36.234.68]) by gandharva.secretlabs.de (Postfix) with ESMTPSA id 16C25121CEF for <dnsop@ietf.org>; Mon, 4 Mar 2019 06:19:09 +0000 (UTC)
From: Holger Freyther <dnsop@freyther.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 04 Mar 2019 06:19:06 +0000
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com>
To: dnsop@ietf.org
In-Reply-To: <155094804613.28045.8648150477440044197@ietfa.amsl.com>
Message-Id: <E3635752-85F1-4EFB-B840-687EB60D361D@freyther.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V_fwFBONHXkc7P7-WMz-RYxb6z8>
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: Mon, 04 Mar 2019 06:19:15 -0000


> On 23. Feb 2019, at 18:54, internet-drafts@ietf.org wrote:
> 


> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-03
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-serve-stale-03


Section 5:

   If so, it adds that data to the response message; it MUST
   set the TTL of each expired record in the message greater than 0,
   with 30 seconds recommended.


Can we recommend to return a value randomly from an interval to add jitter instead? This is a common mitigation to a "thundering herd".




Section 8:

I might have missed some of the discussion but has the point of view of authoritative servers been considered?

What I really liked about a resolver signaling its' intent to stale serve to an authoritative nameserver is that it allows to (dynamically) lower the TTL. This allows an operator to react more quickly to changes without decreasing the resilience by relying on the resolver to cache. It seems equally attractive to both CDNs and "hobbyist" deployments.

Without signaling operators of authoritative nameservers either need to (non exhaustive):

a.) Keep the trade-off between nameserver unavailability and rate of change.
b.) Discriminate based on the resolver address
c.) Wait for further large scale experiments to determine the adoption rate of stale serving.

v2.23.0 | Report a Bug | By Email