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

Ralph Dolmans <ralph@nlnetlabs.nl> Thu, 22 March 2018 11:30 UTC

Return-Path: <ralph@nlnetlabs.nl>
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 6463212420B for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 04:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 gMDfAiS8q9ev for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 04:30:30 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 1ED64120721 for <dnsop@ietf.org>; Thu, 22 Mar 2018 04:30:28 -0700 (PDT)
Received: from [IPv6:2a04:b900:0:1:9421:625a:1921:b449] (unknown [IPv6:2a04:b900:0:1:9421:625a:1921:b449]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0279683BA for <dnsop@ietf.org>; Thu, 22 Mar 2018 12:30:26 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1521718226; bh=dcxASfTVuU/kS5/FRyYfA73GMXXWG8wmgKoJBpXeqk4=; h=Subject:To:References:From:Date:In-Reply-To; b=A+O3gWcXuIbf/qnzi9KjByMr0jP3hl/YnY77ay/mCLllxnMaUwHcRWkxDBoXC5TLH 7IJPhPD4YL0nfwOt5/M8vkKVaDvYqCXdGR8ogNNVLp1lZfkk/XsFBz2PDCbxYa8WKB rUvT0vA3Pgx0i/k8tSnXRyf7CKtXRn3rVcyvWrhc=
To: dnsop@ietf.org
References: <152164652206.7491.752211557326821321.idtracker@ietfa.amsl.com> <a8cdb0db-4e2e-5829-a5eb-2ebafdda5400@nic.cz>
From: Ralph Dolmans <ralph@nlnetlabs.nl>
Message-ID: <025c5d3a-2ff1-066f-8a9b-6c7e2644bee3@nlnetlabs.nl>
Date: Thu, 22 Mar 2018 12:30:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <a8cdb0db-4e2e-5829-a5eb-2ebafdda5400@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Plo7cGpG18Q14N4dPGKnwZrDoMo>
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: Thu, 22 Mar 2018 11:30:31 -0000

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.

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