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

Dave Lawrence <tale@dd.org> Wed, 06 March 2019 01:47 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 20C2F128CB7 for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 17:47:44 -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 AEEJDk7q-9Sr for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 17:47:42 -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 43CD1124BF6 for <dnsop@ietf.org>; Tue, 5 Mar 2019 17:47:42 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 772EF28970; Tue, 5 Mar 2019 20:47:41 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23679.9917.470832.732249@gro.dd.org>
Date: Tue, 5 Mar 2019 20:47:41 -0500
From: Dave Lawrence <tale@dd.org>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <CAL9jLaaUYni-+tyCf0WvXgsKTBSDOC_DSYP92mD1gGbNrjG4xQ@mail.gmail.com>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com> <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com> <4253851.Zqd2zPpPcC@linux-9daj> <92355508-D5AC-46DC-8FF5-C1C4155601D8@isc.org> <alpine.LRH.2.21.1903042240330.32161@bofh.nohats.ca> <CAL9jLabYgYco9JjBmo9g6DHjJ4Z3SsnqpDu=_WMWeo3mSNj-gA@mail.gmail.com> <alpine.LRH.2.21.1903050912170.6450@bofh.nohats.ca> <CAL9jLaaUYni-+tyCf0WvXgsKTBSDOC_DSYP92mD1gGbNrjG4xQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7_1e6pcurd_5GjQE-XcCcpvgqWM>
Subject: Re: [DNSOP] [Ext] 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: Wed, 06 Mar 2019 01:47:44 -0000

Christopher Morrow writes:
> My point is that the recursive reoslver has no idea why an authoritative
> is unreachable and that doing anything like sending stale records is 
> going to cause unintended problems.

Given the operational benefit that has already been observed in
production with serve-stale, I think it needs more than vague fears of
"is going to cause unintended problems" to argue against it.  If we
let unspecified concerns of possible unintended problems be our
guidance we'd never get anything done around here.