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

Paul Vixie <paul@redbarn.org> Wed, 15 November 2017 04:08 UTC

Return-Path: <paul@redbarn.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 A38E812878D for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:08:57 -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 oRRRl3VrBb71 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 20:08:56 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C5112778D for <dnsop@ietf.org>; Tue, 14 Nov 2017 20:08:56 -0800 (PST)
Received: from [10.170.78.140] (unknown [65.158.49.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C37C461FA2; Wed, 15 Nov 2017 04:08:56 +0000 (UTC)
Message-ID: <5A0BBDD7.2070406@redbarn.org>
Date: Tue, 14 Nov 2017 20:08:55 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Dave Lawrence <tale@dd.org>
CC: IETF DNSOP WG <dnsop@ietf.org>
References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <CA+nkc8B1sVhjbn1xYu4rQNgUZGgeaqnVjW=U0nmpRdu6rvXU2Q@mail.gmail.com> <23051.40720.908131.277454@gro.dd.org> <CAHXf=0oQTVe3LFdkGLYH0XL4Vg1Fm5JdnOaOCJ59zwiMkk6MVw@mail.gmail.com> <23051.47926.538193.725450@gro.dd.org>
In-Reply-To: <23051.47926.538193.725450@gro.dd.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I-51BFOVuIeSPjvCdJbU98XIWvM>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 15 Nov 2017 04:08:58 -0000


Dave Lawrence wrote:
> Alexander Mayrhofer writes:
>> I'm torn on the question whether or not stale data should be served
>> (without signaling, in that case) when the request does *not*
>> contain an OPT request.
>
> I'm personally not torn on this; for me the whole point of
> implementing this functionality is to add resiliency to the existing
> DNS ecosystem.  Very specifically for my implementation it was needed
> in an environment where answers were going to a stub resolver that did
> not (and still does not) speak EDNS.
>
> It is significantly less operationally beneficial if it demands EDNS.

i'm of the opposite view. we should not change behaviour without 
explicit signaling. if that means it takes 10 years to reach 50% 
penetration, like EDNS did, then that's the cost of doing business.

-- 
P Vixie