Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Florian Weimer <fw@deneb.enyo.de> Sun, 22 March 2015 18:55 UTC

Return-Path: <fw@deneb.enyo.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2E1A0155 for <dnsop@ietfa.amsl.com>; Sun, 22 Mar 2015 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.16
X-Spam-Level:
X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Y2Nbt8o1YspG for <dnsop@ietfa.amsl.com>; Sun, 22 Mar 2015 11:55:48 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D01A0120 for <dnsop@ietf.org>; Sun, 22 Mar 2015 11:55:48 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1YZl2F-0001BG-Ua; Sun, 22 Mar 2015 19:55:44 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1YZl2F-0007o3-Lq; Sun, 22 Mar 2015 19:55:43 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Paul Vixie <paul@redbarn.org>
References: <20150318013805.GH4385@mx1.yitter.info> <55093E8C.3030300@redbarn.org> <550A8F58.2040009@nlnetlabs.nl> <87a8z630ed.fsf@mid.deneb.enyo.de> <550DB3B0.3080601@redbarn.org>
Date: Sun, 22 Mar 2015 19:55:43 +0100
In-Reply-To: <550DB3B0.3080601@redbarn.org> (Paul Vixie's message of "Sat, 21 Mar 2015 11:08:48 -0700")
Message-ID: <87lhio980g.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/gODARefZQFR7SRvqlxTxqHT8zoU>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 22 Mar 2015 18:55:50 -0000

* Paul Vixie:

>> As a counterexample, RFC 6891 requires FORMERR responses without OPT
>> RRs from implementations which do not support EDNS:
>>
>>    Responders that choose not to implement the protocol extensions
>>    defined in this document MUST respond with a return code (RCODE) of
>>    FORMERR to messages containing an OPT record in the additional
>>    section and MUST NOT include an OPT record in the response.
>
> this language was very careful. older implementations cannot
> "choose" behaviour relative to this standard. so, as an example of
> what you're trying to convey, this text fails.

They could patch the RCODE in the header and reflect the packet.  That
used to be a valid implementation option, and it was sort-of assumed
by the previous EDNS0 version with its extended label types.  It was
the only way to generate a FORMERR response when you could not parse
even the QNAME.  (Or you could say that EDNS0 encouraged matching
responses based on transaction IDs only, but let's not go there.)