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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 14 November 2017 07:32 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 8146C129490 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 23:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wH0fjbWqdWHM for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 23:32:29 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C471293DA for <dnsop@ietf.org>; Mon, 13 Nov 2017 23:32:28 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C148E7A330A; Tue, 14 Nov 2017 07:32:27 +0000 (UTC)
Date: Tue, 14 Nov 2017 07:32:27 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20171114073227.GO3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <alpine.DEB.2.11.1711131236140.14243@grey.csi.cam.ac.uk> <yblmv3psjmk.fsf@wu.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <yblmv3psjmk.fsf@wu.hardakers.net>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/91ZPdYxF2IkL2_qSV5Fo4g9bmrY>
Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error
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: Tue, 14 Nov 2017 07:32:30 -0000

On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote:

> Tony Finch <dot@dotat.at> 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.

-- 
	Viktor.