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

Dave Lawrence <tale@dd.org> Wed, 06 March 2019 16:27 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 0A6F6127980 for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 08:27:21 -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 NI_vmHU6xXQU for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 08:27:19 -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 1FB3712796D for <dnsop@ietf.org>; Wed, 6 Mar 2019 08:27:19 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 1DB8728F7C; Wed, 6 Mar 2019 11:27:18 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23679.62694.104026.271181@gro.dd.org>
Date: Wed, 06 Mar 2019 11:27:18 -0500
From: Dave Lawrence <tale@dd.org>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <3BCC02A3-9F05-4A35-A06E-D69719EB7CB5@hopcount.ca>
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> <23678.40176.492174.37630@gro.dd.org> <3E7AF476-0989-4FA8-8186-F5AAFC87317A@icann.org> <alpine.LRH.2.21.1903051202360.1124@bofh.nohats.ca> <23679.9798.678631.923122@gro.dd.org> <alpine.DEB.2.20.1903061237440.17454@grey.csi.cam.ac.uk> <3BCC02A3-9F05-4A35-A06E-D69719EB7CB5@hopcount.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3gWzBoR0H1Un9Aw1YiJG7RAgA3U>
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 16:27:21 -0000

Joe Abley writes:
> if you can find a set of DNS authority servers that silently
> discards a particular kind of query, sending such queries through
> resolvers that are known to support serve-stale might suppress other
> queries and trigger the serve-stale behaviour even though the
> authority servers are not actually unresponsive for them.

RFC 2308 section 7.2 made it clear that when caching a dead server
indication, "The indication MUST be stored against query tuple <query
name, type, class, server IP address> unless there was a transport
layer indication that the server does not exist, in which case it
applies to all queries to that specific IP address."

The scenario described in one of a resolver that is modern enough to
have implemented standards-compliant serve-stale behavior but is still
not standards-compliant with a two decade old RFC, interacting over a
path with a delegation to authoritative servers that are all
exhibiting erratic behavior.  This needs some supporting evidence that
it could really be a real-world problem that needs to be addressed.