Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt

Mark Andrews <marka@isc.org> Fri, 23 March 2018 02:05 UTC

Return-Path: <marka@isc.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 2F32E1270FC for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 19:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 MgSYQxMW7Hxt for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 19:05:08 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0752126B7E for <dnsop@ietf.org>; Thu, 22 Mar 2018 19:05:08 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 86C093AB002; Fri, 23 Mar 2018 02:05:07 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 77FC7160047; Fri, 23 Mar 2018 02:05:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 67743160067; Fri, 23 Mar 2018 02:05:07 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zUYknjY-dm9i; Fri, 23 Mar 2018 02:05:07 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B947D160047; Fri, 23 Mar 2018 02:05:06 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <025c5d3a-2ff1-066f-8a9b-6c7e2644bee3@nlnetlabs.nl>
Date: Fri, 23 Mar 2018 13:05:04 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2C5F8CB-5326-47FC-A547-1BC814CFCB12@isc.org>
References: <152164652206.7491.752211557326821321.idtracker@ietfa.amsl.com> <a8cdb0db-4e2e-5829-a5eb-2ebafdda5400@nic.cz> <025c5d3a-2ff1-066f-8a9b-6c7e2644bee3@nlnetlabs.nl>
To: Ralph Dolmans <ralph@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_GhFKchaSIG5Sv7baSCSpmQjAT0>
Subject: Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-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: Fri, 23 Mar 2018 02:05:10 -0000

> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans <ralph@nlnetlabs.nl>; wrote:
> 
> Hi,
> 
> On 21-03-18 16:58, Petr Špaček wrote:
>> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
>> The Camel talk from yesterday, and is based on plan of open-source DNS
>> software vendors to get rid of EDNS workarounds.
> 
>> From the introduction:
> 
>> EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant
>>   implementations still exist and cause lot of extra queries and
>>   complicated logic in recursive resolvers.  RFC 6891 clearly states
>>   that FORMERR is the only acceptable answer for implementations
>>   without support for EDNS.
> 
> This is, although factual correct, somewhat misleading. Yes EDNS0 is
> standardized in 1999, but that is not the later mentioned RFC6891 (from
> 2013) that requires a FORMERR RCODE. RFC2761 from 1999 talks about
> "NOTIMPL, FORMERR, or SERVFAIL". I also fail to understand the relation
> with RFC1035 in the first sentence.

RFC 1035 says to return FORMERR to a EDNS request. Yes, RFC 1035 said how
to handle unknown extensions. That is what the expected behaviour of a 
STD 13 compliant server *is*.  Non STD 13 compliant servers returned 
NOTIMPL and SERVFAIL.  RFC2761 reported what was seen in the wild. 
FORMERR was the dominate rcode at the time. I don’t see anything other
than FORMERR or NOERROR these days to a plain EDNS(0) query from a non-EDNS
aware server.

> Also the "The Protocol" section does not mention that the retrieved
> RCODE (if any) is relevant in the decision whether to retry with or
> without EDNS.
> 
> -- Ralph
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org