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

Paul Vixie <paul@redbarn.org> Wed, 15 November 2017 03:36 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 ECBB01274A5 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:36:29 -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 0dXbVjO6R11C for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 19:36:29 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF91126CBF for <dnsop@ietf.org>; Tue, 14 Nov 2017 19:36:29 -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 D0AF361FA2; Wed, 15 Nov 2017 03:36:28 +0000 (UTC)
Message-ID: <5A0BB63B.70607@redbarn.org>
Date: Tue, 14 Nov 2017 19:36:27 -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>
In-Reply-To: <23051.40720.908131.277454@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/cijNZqyPcPD2RY6Ria7shsn6Y9E>
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:36:30 -0000


Dave Lawrence wrote:
> Bob Harold writes:
>> I am a little concerned about yet another option that the client
>> might want to send with every query.  Can the existence of *any*
>> EDNS option from the client be taken to mean that EDNS options are
>> understood in general, and the resolver is ok to respond with this
>> ENDS option, which the client might not understand but will not choke on?
>
> I personally am of the belief that yes, if the request has an OPT then
> a responder can include an option code that was not in the request.
> At least I don't see anything in 6891 to prohibit it.  This is
> behaviour that draft-ietf-dnsop-extended-error is also expecting.

while i've seen every kind of misbehaviour from EDNS responders, i've 
yet to suspect that an initiator who knows EDNS in any form will choke 
on, or syslog about, unrecognized options in the response. so, +1 to tale.

-- 
P Vixie