[DNSOP] responses to dnsop extended errors comments

Wes Hardaker <wjhns1@hardakers.net> Sat, 10 August 2019 05:27 UTC

Return-Path: <wjhns1@hardakers.net>
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 DD3791200CD for <dnsop@ietfa.amsl.com>; Fri, 9 Aug 2019 22:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UgOwspTzq9Dr for <dnsop@ietfa.amsl.com>; Fri, 9 Aug 2019 22:26:59 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F1312004D for <dnsop@ietf.org>; Fri, 9 Aug 2019 22:26:59 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 857CC2AFC5; Fri, 9 Aug 2019 22:26:57 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Date: Fri, 09 Aug 2019 22:26:57 -0700
Message-ID: <yblk1blio9q.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Rgnb_G1eCFUpHwt6rLSsOiCgUNQ>
Subject: [DNSOP] responses to dnsop extended errors comments
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: Sat, 10 Aug 2019 05:27:04 -0000

Thanks for your feedback about the extended errors draft.  Below are
responses to some of your previously raised points in email to dnsop:

8.2 Stephane Bortzmeyer
~~~~~~~~~~~~~~~~~~~~~~~

  At the IETF 104 hackathon in Prague, Vladimír Čunát and myself
  implemented it in the Knot resolver
  [https://www.knot-resolver.cz/]. You can see the result in the git
  merge request
  [https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/794]
  (branch extended_error
  [https://gitlab.labs.nic.cz/knot/knot-resolver/tree/extended_error]).


8.2.1 DONE > 4.1.5.  SERVFAIL Extended DNS Error Code 5 - DNSSEC Indeterminate
------------------------------------------------------------------------------

  >   The resolver attempted to perform DNSSEC validation, but
  >   validation ended in the Indeterminate state.  The R flag should
  >   not be set.

  Isn't there an error here? 4.1 is the section for NOERROR. What should
  be returned for DNSSEC Indeterminate? NOERROR or SERVFAIL? (In the
  first case, change the text, in the second, move this paragraph to
  4.2.)

  Now, implementation experience. We tested with Wireshark and dig (did
  not try to develop a client using the extended error code, just the
  server).

  As expected, producing extended error codes is quite simple and the
  draft is clear. The camel will be happy.

  + Response: With the recent removal of the RCODE binding, I think this
    problem goes away.  Correct?


8.2.2 DONE The biggest issue is of course to find out what to put in the extended
---------------------------------------------------------------------------------

  error code. On some resolvers (at least on Knot), the place where the
  error is noticed can be quite far from the place where the answer is
  built, with its EDNS options. In practice, we had to add data to the
  request object, for the extended error information to be carried to
  the module that emits the extended error code EDNS option. So, the
  real difficulty is not in the draft, but in knowing and understanding
  your resolver.

  + Response: As agreed to in IETF105, we've removed the RCODE binding.

    Some details:


8.2.3 NOCHANGE * no resolver will use all the response-code/info-codes because some
-----------------------------------------------------------------------------------

  are never reached for this resolver, or are mixed with other
  issues. Generic errors (such as "SERVFAIL Extended DNS Error Code 1 -
  DNSSEC Bogus") are useful for when you cannot reliably find the
  problem.

  + Response: I'm not sure what change you're suggesting.  Removal of
    the binding may help, and I don't think there is an expectation that
    every implementation should be able to return every code.  I'd
    expect the union of all implementations to find the ability to
    return each code, but not each implementation itself?


8.2.4 DONE * the draft is silent about the laying out of bits in info-code. Not
-------------------------------------------------------------------------------

  many IETF protocols have an integer field which is larger than a byte
  but not byte-aligned.

  + Response: Good point; added encoding rules (MSB)


8.2.5 NOCHANGE * the draft has a passing mention that multiple extended error options
-------------------------------------------------------------------------------------

  are allowed but I don't see how it could be used by the poor client
  trying to figure out what happened. I suggest to disallow it.

  + Response: Most clients should be logging the resulting findings, or
    displaying them maybe.  We don't expect this option to be used for
    anything other than debugging, especially because its not
    authenticated.  The client also has to be prepared to accept
    multiple options anyway, as not doing so is equally as problematic
    (IE, assuming no one will send you more than one option is a sure
    path to crashing or other problem)


8.2.6 NOCHANGE * the draft has (rightly so) two info-codes for NXDOMAIN/Blocked and
-----------------------------------------------------------------------------------

  NXDOMAIN/Censored but Knot cannot use it currently since the policy
  module (written in Lua) has no way today to be configured to express
  the difference. Not a problem in the draft but it will be probably a
  common case that the resolver cannot make use of *all* codes.

  + Response: Yep, per above I suspect different implementations may
    need to return different codes based on their implementation needs.
    The point is to turn the right code to help users/debuggers.


8.2.7 NOCHANGE Let's end with a few examples:
---------------------------------------------

  4.2.2.  SERVFAIL Extended DNS Error Code 2 - Signature Expired

  % dig @::1 -p 9053 A servfail.nl ...  ;; ->>HEADER<<- opcode: QUERY,
  status: SERVFAIL, id: 12100 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
  AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION: EDNS: version: 0, flags: do; udp: 4096
  ; OPT=65500: 00 00 20 02 44 4e 53 53 45 43 20 65 78 70 69 72 65 64 20
  ; 73 69 67 6e 61 74 75 72 65 73 (".. .DNSSEC expired signatures") ...


  4.2.7.  SERVFAIL Extended DNS Error Code 7 - No Reachable Authority

  % dig @::1 -p 9053 A brk.internautique.fr ...  ;; ->>HEADER<<- opcode:
  QUERY, status: SERVFAIL, id: 38620 ;; flags: qr rd ra; QUERY: 1,
  ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION: EDNS: version: 0, flags: do; udp: 4096
  ; OPT=65500: 80 00 20 07 6e 6f 20 4e 53 20 77 69 74 68 20 61 6e 20 61
  ; 64 64 72 65 73 73 (".. .no NS with an address") ...

  (Not an ideal message but this is quite generic code in Knot.)


  4.5.1.  NXDOMAIN Extended DNS Error Code 1 - Blocked

  % dig @::1 -p 9053 A googleanalytics.com ...  ;; ->>HEADER<<- opcode:
  QUERY, status: NXDOMAIN, id: 1189 ;; flags: qr aa rd ra; QUERY: 1,
  ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

  ;; OPT PSEUDOSECTION: EDNS: version: 0, flags: do; udp: 4096
  ; OPT=65500: 80 00 30 01 4e 6f 20 74 72 61 63 6b 69 6e 67 ("..0.No
  ; tracking") ; QUESTION SECTION: googleanalytics.com. IN A

  ;; AUTHORITY SECTION: googleanalytics.com. 10800 IN SOA
  googleanalytics.com. nobody.invalid. ( 1 ; serial 3600 ; refresh (1
  hour) 1200 ; retry (20 minutes) 604800 ; expire (1 week) 10800 ;
  minimum (3 hours) )

  ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "No tracking"


-- 
Wes Hardaker
USC/ISI