Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 13 September 2019 17:02 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 CA95F1200D5 for <dnsop@ietfa.amsl.com>; Fri, 13 Sep 2019 10:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CcYGbu-OzZE2 for <dnsop@ietfa.amsl.com>; Fri, 13 Sep 2019 10:02:11 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F8E1200FA for <dnsop@ietf.org>; Fri, 13 Sep 2019 10:02:11 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id F33EF2A69D0 for <dnsop@ietf.org>; Fri, 13 Sep 2019 13:02:09 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <F7A157E6-9773-4B6F-90C8-761D1B3CFC00@icann.org>
Date: Fri, 13 Sep 2019 13:02:07 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <AACC9277-D817-4384-99D9-4F65EE809F0C@dukhovni.org>
References: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org> <ybl36h4aj8x.fsf@w7.hardakers.net> <AFE92D06-8418-4451-A827-D5656C83B796@icann.org> <yblzhjbeova.fsf@w7.hardakers.net> <067589D2-8E7E-47FA-867C-72E266A55D6D@icann.org> <CADyWQ+EB-eotvTdYwNv5Oo4=-mibdgEgpkQ3yh37orAwp-AgWg@mail.gmail.com> <ybly2yubfnp.fsf@w7.hardakers.net> <21136294-FDFD-4A99-9529-E79C45E79535@icann.org> <yblzhja9kz3.fsf@w7.hardakers.net> <3AC375B1-D858-4577-AEBE-4BB7CD40C241@icann.org> <1878161734.14716.1568306548325@appsuite-gw1.open-xchange.com> <0C5DC6B2-E9C5-46A6-B0BA-12830A405DD2@dukhovni.org> <775d97e3-65b0-832a-6118-a3c64d872539@bellis.me.uk> <F7A157E6-9773-4B6F-90C8-761D1B3CFC00@icann.org>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LTMSjMvpz3a2vMA2RrS9yBREXDo>
Subject: Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Sep 2019 17:02:14 -0000

> On Sep 13, 2019, at 9:38 AM, Paul Hoffman <paul.hoffman@icann.org>; wrote:
> 
>> "There are many reasons that a DNS query may fail, some of them
>> transient, some permanent; some can be resolved by querying another
>> server, some are likely best handled by stopping resolution.
>> Unfortunately, the error signals that a DNS server can return are
>> very limited, and are not very expressive."
> 
> Fully agree. That's why I'm pressing for clarification by addition of determinative text, not just removal of confusing text.

If more fine-grained RCODEs are needed, then perhaps bite
the bullet and add them as EXTENDED-RCODEs in the currently
unassigned range:

       23 - 3,840
   0x0017 - 0x0F00

with the limitation that new EXTENDED-RCODE values are for
legacy clients implicitly refinements of SERVFAIL, since a
client that does not understand a new RCODE can only treat
it as some sort of unknown failure.

With EDEs as largely diagnostic refinement, the EXTENDED-RCODE
remains unchanged and dispositive, and the EDE do not generally
change client behaviour.

There are perhaps cases where a client might choose to not retry
a query that returned REFUSED when the EDE is:

  3.16. Extended DNS Error Code 15 - Blocked
  3.17. Extended DNS Error Code 16 - Censored
  3.18. Extended DNS Error Code 17 - Prohibited
  3.19. Extended DNS Error Code 18 - Filtered
  3.22. Extended DNS Error Code 21 - Deprecated

or not retry a SERVFAIL when the EDE is:

  3.21. Extended DNS Error Code 20 - Lame

if it is reasonable to expect the same response from any
other nameservers one might use in retries.  Is it the
intent of this draft that the above or similar would
be used by some clients to make retry/abort decisions?

If so, perhaps it then makes sense to specify the EXTENDED-RCODE + EDE
combinations that go beyond mere diagnostic information, and would be
potential "permanent" errors.

If an iterative resolver encounters a REFUSED from its upstream,
in combination with one of the "permanent" EDEs, might it then
in turn return REFUSED with the same EDE to its client (without
retrying) rather than SERVFAIL after exhausting all upstream
servers (presumably its present behaviour)?

-- 
	Viktor.