IETF Logo Mail Archive

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Ray Bellis <ray@bellis.me.uk> Mon, 13 November 2017 12:53 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 4D15612941C for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 04:53:52 -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 faYisQXPtbhn for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 04:53:50 -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 A00651292F4 for <dnsop@ietf.org>; Mon, 13 Nov 2017 04:53:50 -0800 (PST)
Received: from [42.61.209.129] (port=50209 helo=rays-mbp.local) 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 1eEEFH-0002L7-GG (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Mon, 13 Nov 2017 12:53:47 +0000
To: dnsop@ietf.org
References: <yblpo9md8fk.fsf@wu.hardakers.net> <CADyWQ+G-e+zqGkFK7vPQdXBDRvyv-Gxw75N1z+A6L8ULR=+izQ@mail.gmail.com> <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <e9a3bbc4-0c03-b66c-eb2b-a1c1b336424b@bellis.me.uk>
Date: Mon, 13 Nov 2017 20:54:16 +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: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Dh8njH31kvN7gop9dd10qw2SrxE>
Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options
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: Mon, 13 Nov 2017 12:53:52 -0000


On 13/11/2017 19:01, Geoff Huston wrote:

> errr - what would it mean if the rcode in the error code header differed
> from the rcode value in the extended-error component?
> 
> The issue with duplicated information in a packet is that you then have
> add even further consideration to cope with the cases where the expected
> thing did not happen.
> 
> Not exactly blown away by #4 myself.

Would it be feasible to reserve a standard RCODE value in the header
that just means "see extended error"?

It has always kinda surprised me that the EDNS RCODE didn't work that
way, instead of the current situation where if you only read the bottom
4 bits of the extended 12-bit code you could completely misinterpret the
status (e.g. treat BADVER[16] as NOERROR[0], since the bottom four bits
are all zeros for both).

Ray

v2.14.0 | Report a Bug | By Email