Re: Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard

Stephane Bortzmeyer <bortzmeyer@nic.fr> Sat, 14 September 2019 12:38 UTC

Return-Path: <stephane@sources.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E26E120077; Sat, 14 Sep 2019 05:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, 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 1w9nfRHUtSoK; Sat, 14 Sep 2019 05:38:08 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 2007E120072; Sat, 14 Sep 2019 05:38:08 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id C3593A052F; Sat, 14 Sep 2019 14:38:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 886E51908BD; Sat, 14 Sep 2019 14:34:25 +0200 (CEST)
Date: Sat, 14 Sep 2019 14:34:25 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: S Moonesamy <sm+ietf@elandsys.com>
Cc: ietf@ietf.org, draft-ietf-dnsop-serve-stale@ietf.org
Subject: Re: Last Call: <draft-ietf-dnsop-serve-stale-07.txt> (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
Message-ID: <20190914123425.zpsbvhdw57mopbcs@sources.org>
References: <156821841762.13409.15153693738152466982.idtracker@ietfa.amsl.com> <6.2.5.6.2.20190911114140.0ea2b0d8@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20190911114140.0ea2b0d8@elandnews.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.9
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2tRKamXxTwixZwhUnz_w450Se9M>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 12:38:09 -0000

On Wed, Sep 11, 2019 at 11:55:04AM -0700,
 S Moonesamy <sm+ietf@elandsys.com> wrote 
 a message of 18 lines which said:

> There is the following recommendation in Section 4: "When returning
> a response containing stale records, a recursive resolver MUST set
> the TTL of each expired record in the message to a value greater
> than 0, with 30 seconds RECOMMENDED".  Where does the "30 seconds"
> come from?

It comes from the fact that it is the upper recommended value between
retrials by the resolver (section 5). So, a downstream client has no
reason to try again before 30 seconds.

The reasons of this choice (why 30) are in section 6: "Other very
short TTLs could lead to congestive collapse as TTL-respecting clients
rapidly try to refresh.  The recommended value of 30 seconds not only
sidesteps those potential problems with no practical negative
consequences, it also rate limits further queries from any client that
honors the TTL, such as a forwarding resolver."