Re: [DNSOP] About draft-ietf-dnsop-extended-error

Shane Kerr <> Tue, 14 November 2017 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 578031292C5 for <>; Mon, 13 Nov 2017 23:56:58 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HcJxAwxb6I3R for <>; Mon, 13 Nov 2017 23:56:57 -0800 (PST)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2831126C23 for <>; Mon, 13 Nov 2017 23:56:56 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1eEW7p-0005Jr-0H for; Tue, 14 Nov 2017 07:59:17 +0000
References: <> <> <> <>
From: Shane Kerr <>
Message-ID: <>
Date: Tue, 14 Nov 2017 07:56:00 +0000
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2017 07:56:58 -0000


Viktor Dukhovni:
> On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote:
>> Tony Finch <> writes:
>>>> It can be argued that NODATA (pseudo rcode, I know) is an "error" as
>>>> well as NXDOMAIN...
>>> Or, neither of them are errors :-)
>> We'll remove the restriction in any wording that says it can only be for
>> errors.  I think there is clear consensus to do so.
> For the record, I'm with Tony, neither NODATA nor NXDomain are DNS
> lookup errors.  Lack of answers may (or may not) lead to
> application-level errors depending on whether the data sought was
> functionally essential, but either way the DNS lookup was successful,
> and returned the status of the requested RRset.
> This is, for example, important with opportunistic DANE TLS, where
> actual lookup errors are potential downgrade attacks, but NODATA
> and NXDomain are not lookup errors.
> And indeed unlike actual errors, there is nothing one could possibly
> add in the form extended "error" diagnostics when returning a NODATA
> or NXDomain response, these non-error conditions don't require any
> additional context to aid problem resolution.

Be careful when you say "nothing ... possibly". ;)

For example, you could have something like:

Extended code: ERRBLACKLIST
Explanation: "Client blacklisted for IPv6 queries"

This could be helpful for a user or operator. (Of course, it also hints
that being able to add arbitrary text to an error may be useful, as
including a URL with more information in the response might provide
further insight. But perhaps having Google is enough that this is not