Re: [DNSOP] Implementations of extended error?

Wes Hardaker <> Tue, 05 February 2019 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 665C5124BAA for <>; Tue, 5 Feb 2019 10:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CfZHVUoFuVvk for <>; Tue, 5 Feb 2019 10:59:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 792C012008F for <>; Tue, 5 Feb 2019 10:59:43 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id 8EEE4225F2; Tue, 5 Feb 2019 09:03:07 -0800 (PST)
From: Wes Hardaker <>
To: Shane Kerr <>
Cc: Wes Hardaker <>,
References: <> <> <> <>
Date: Tue, 05 Feb 2019 09:03:07 -0800
In-Reply-To: <> (Shane Kerr's message of "Mon, 4 Feb 2019 11:51:03 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [DNSOP] Implementations of 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, 05 Feb 2019 18:59:46 -0000

Shane Kerr <> writes:

> My own thinking is that extended error is much more important on the
> resolver side than on the authoritative side, so that's what I was
> asking about.

That's fair; it's a generic mechanism but authoritative servers have less
reason to return most of the codes (though I cloud see Prohibited and
Blocked being useful for authoratatives).

(And actually, I just read the "Lame" description in the draft, and it's
actually broken.  It should talk about what to do for both.  I've now fixed
that and will push a new version)

> There was some discussion that it might be tricky to get correct
> information out of the bowels of a resolver that wasn't designed with
> this sort of reporting in mind.

Yeah, I suspect there are some code bases that this simply won't work with EDE
without a major rearchitecture.  If they're currently returning a
single error code from the depths of a stack trace, they won't be able
to easily return either a double-code or potentially modify their
codes to be more descriptive.  Then we get to "error text" as well and
it gets worse.

> Here's what I took away (people can and should correct me where I am wrong):

Thanks for the summary!  Sounds like it was a good discussion.

Wes Hardaker