Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt

Wes Hardaker <> Tue, 05 May 2020 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF66A3A0BB1 for <>; Tue, 5 May 2020 14:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fZjV7rAFS-rp for <>; Tue, 5 May 2020 14:38:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B1103A0BCE for <>; Tue, 5 May 2020 14:38:53 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id C56F42C86C; Tue, 5 May 2020 14:38:52 -0700 (PDT)
From: Wes Hardaker <>
To: Eric Orth <>
Cc: dnsop <>
References: <> <>
Date: Tue, 05 May 2020 14:38:52 -0700
In-Reply-To: <> (Eric Orth's message of "Fri, 24 Apr 2020 15:15:27 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt
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, 05 May 2020 21:38:55 -0000

Eric Orth <> writes:

> "Because long EXTRA-TEXT fields may trigger truncation, which is undesirable given
> the supplemental nature of EDE.  Implementers and operators creating EDE options SHOULD avoid
> lengthy EXTRA-TEXT contents."

Thanks for pointing that out; it was indeed a failed edit at a different
problem and has been fixed.

> "As such, EDE content should be treated only as diagnostic information and MUST NOT alter DNS
> protocol processing."
> (Sorry for not getting back and responding further on this subject in
> the previous thread.)

And I'm sorry for delaying getting back to you about you getting back to
me about me getting...  anyway.

FYI, at least two of the authors agree with you, as resolvers are
already making decisions based on unauthenticated information (rcodes).
But this has been heavily discussed (multiple times) in the WG and the
conclusion was that EDE cannot alter processing, hence the strong
language.  So in the end we didn't change the text to soften it, as it
would counter the decisions of the larger past discussions.
Wes Hardaker