Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

Ray Bellis <> Tue, 30 October 2018 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD7391292F1 for <>; Tue, 30 Oct 2018 10:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bo-IIHm-1jkr for <>; Tue, 30 Oct 2018 10:21:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDBFC128D09 for <>; Tue, 30 Oct 2018 10:21:55 -0700 (PDT)
Received: from [] (port=61739 helo=Rays-MacBook-Pro.local) by ([]:465) with esmtpsa ( (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1gHXiB-0000PA-8C (Exim 4.72) for (return-path <>); Tue, 30 Oct 2018 17:21:51 +0000
References: <> <> <>
From: Ray Bellis <>
Message-ID: <>
Date: Tue, 30 Oct 2018 17:21:53 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------E1AB0DF675BCA3AD14E8EB26"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2018 17:21:58 -0000

On 30/10/2018 16:57, Wes Hardaker wrote:

> Well, the plan is to not allow it per the original EDNS0 spec.  We
> should have said that in the section and said "going once...." or
> something.  IE, the plan is to disallow sending it back unless the
> source indicates support.
> [In theory, it should be possible to always include it because of the
> "ignore additional you don't understand" rule]

Except that RFC 6891 expressly prohibits that (§7):

   Lack of presence of an OPT record in a request MUST be taken as an
   indication that the requestor does not implement any part of this
   specification and that the responder MUST NOT include an OPT record
   in its response.

FWIW, I really wish in retrospect that EDNS(0) had defined the extra
rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL
is always "2" in those four bits in the main header, with the extended
field in the EDNS response allowing for more detail (c.f. this draft).

Unfortunately with the newer RCODEs just being assigned contigiously
from 16 onwards that's no longer possible :(

As it is, if you send extended RCODE 18 (BADTIME) in a packet a non
EDNS-aware client will only see RCODE 2, which is probably in large part
why we have the very stricture quoted above.