IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Mark Andrews <marka@isc.org> Fri, 28 July 2017 00:54 UTC

Return-Path: <marka@isc.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 5B192131EC4 for <dnsop@ietfa.amsl.com>; Thu, 27 Jul 2017 17:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 PktKXTCCJZ0U for <dnsop@ietfa.amsl.com>; Thu, 27 Jul 2017 17:54:52 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA73131EC3 for <dnsop@ietf.org>; Thu, 27 Jul 2017 17:54:52 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F1D293496AB; Fri, 28 Jul 2017 00:54:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DD3F4160036; Fri, 28 Jul 2017 00:54:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AF9B0160074; Fri, 28 Jul 2017 00:54:49 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NfioY9hzeTxN; Fri, 28 Jul 2017 00:54:49 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5F9DB160036; Fri, 28 Jul 2017 00:54:49 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1A1C9802EA24; Fri, 28 Jul 2017 10:54:47 +1000 (AEST)
To: Roy Arends <roy@dnss.ec>
Cc: Shane Kerr <shane@time-travellers.org>, tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <CADyWQ+Ffu8JOn6co184PC-Uvv4G1qYU3d0ZchupRJEDDmfYKaw@mail.gmail.com> <20170727080827.365d64bf@earth.zonnestelsel.tk> <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec>
In-reply-to: Your message of "Thu, 27 Jul 2017 11:34:20 +0100." <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec>
Date: Fri, 28 Jul 2017 10:54:47 +1000
Message-Id: <20170728005447.1A1C9802EA24@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eS3Y0VSx3DBMQqC3OqSqwp14rDk>
Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-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: Fri, 28 Jul 2017 00:54:54 -0000

In message <4DD39053-3E33-4BD1-A83D-F81219484519@dnss.ec>, Roy Arends writes:
> > On 27 Jul 2017, at 09:08, Shane Kerr <shane@time-travellers.org> wrote:
> > 
> > I support the draft, and am willing to contribute text and review!
> > 
> > I have a few points now, in fact:
> > 
> > 1. Does it make sense to divide the response codes up into those
> >   corresponding to each error type? That is, something like 1xxxx for
> >   SERVFAIL, 2xxxx for FORMERR, and so on?
> 
> Loving this idea. 3xxxx for REFUSED.
> 
> > 2. Do we mind having lots of error codes? For example, we can go really
> >   far and do things likes DNSERR_BADCOMPRESS "name compression used
> >   in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than
> >   255 bytes", and so on. We could end up with hundreds of error codes.
> >   As a developer I don't mind this too much, as these provide hints
> >   about stuff you should be considering, but I can see why some people
> >   would prefer to keep it simple.
> 
> Really like this as well. I think it is really helpful.
> > 
> > 3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451
> >   for consistency with the HTTP response code. This may be a useful
> >   addition to the RPZ draft. ;)
> 
> Sure.
> 
> Roy

Well if we want to add new error code we need to bump the EDNS
version field or otherwise indicate that the client supports new
error codes.

NXRRSET instead of NOERROR with NODATA
NOTAUTH instead of REFUSED when not configured to
	serve the query's namespace.  We already do this for AXFR / IXFR.

If we want to reattempt to add new labels types a more precise error
code would be useful.  In this case the use of the new label type
would be a signal that the error code (and EDNS) is understood.
Query minimisation is also required to achieve this as then only
the servers for zones with such labels need to support the label
type.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email