IETF Logo Mail Archive

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

Ray Bellis <ray@bellis.me.uk> Wed, 15 November 2017 03:51 UTC

Return-Path: <ray@bellis.me.uk>
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 CA2B0129436 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:51:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IsP0zhcdnWxy for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:51:23 -0800 (PST)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BEC127698 for <dnsop@ietf.org>; Tue, 14 Nov 2017 19:51:23 -0800 (PST)
Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:51528) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eEojN-0003Su-8O (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Wed, 15 Nov 2017 03:51:17 +0000
To: 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>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk>
Date: Wed, 15 Nov 2017 11:51:20 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAHXf=0oQTVe3LFdkGLYH0XL4Vg1Fm5JdnOaOCJ59zwiMkk6MVw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s1fiCslNQRkm5rAhsQqLhj6a_nY>
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 03:51:26 -0000

On 15/11/2017 11:47, Alexander Mayrhofer wrote:

> I agree that signaling is important, and i also believe that if
> there's an OPT in the request, we can safely assume that the client
> would not choke on this option. 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. Probably we should err
> on the side of *not* serving stale when a client is not "EDNS
> capable", because that would mean no change from current behaviour.

I'm not particularly arguing either way on this question of signalling,
but do we have any feel for how many stubs ever send EDNS?

libresolv can do it, and getdns does, but I don't think glibc's resolver
routinely sends EDNS.

Ray

v2.23.0 | Report a Bug | By Email