Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

[Viktor Dukhovni <[e-mail]>]

On Tue, Sep 10, 2019 at 08:45:36PM -0700, [e-mail] wrote:

> 	Filename        : draft-ietf-dnsop-extended-error-09.txt

Introduction 3rd paragraph (missing verb, extra period):

       [...] These extended DNS error codes [are?] described in this
       document and can be used by any system that sends DNS queries
       and receives a response containing an EDE option.. [...]

With respect to the much discussed caveat:

       This document does not allow or prohibit any particular extended
       error codes and information be matched with any particular RCODEs.
       Some combinations of extended error codes and RCODEs may seem
       nonsensical (such as resolver-specific extended error codes in
       responses from authoritative servers), so systems interpreting the
       extended error codes MUST NOT assume that a combination will make
       sense.  Receivers MUST be able to accept EDE codes and EXTRA-TEXT in
       all messages, including even those with a NOERROR RCODE.

    My take is that when the (12 bit EDNS) RCODE and new extended error
    are in apparent conflict, I should treat the RCODE as definitive,
    and ignore the extended error code.  That is, the extended error
    can *refine* but not contradict the status indicated by the RCODE.
    If that's correct, perhaps it should be stated explicitly.  If not
    correct, then a clarification is perhaps still in order.

Section 2, 3rd bullet:  s/index to/index into/

      The INFO-CODE serves as an index to the "Extended DNS
      Errors" registry Section 4.1.

Section 2, 4th bullet: s/be take/be taken/

      Care should be take not to leak private information that an
      observer would not otherwise have access to, such as account
      numbers.

   I find "such as account numbers" a bit of a non sequitur (what
   account numbers?) I'd drop this, or produce a more transparent
   example.

Section 3.2 (code 2), may warrant more guidance on when this is
appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
being unsupported, provided the same holds for the DS RRset.  So,
while I see a use-case for code 3 (all DS unsupported, perhaps to
signal why the AD bit is not set, despite the non-empty DS RRset),
I don't understand when one would use code 2.

Section 3.6, code 6 (indeterminate answer) needs clarification,
since there is no single defintion of "indeterminate" in DNSSEC.
In particular different definitions are given in RFCs 4034 and
4035 (as explained in <https://tools.ietf.org/html/rfc7672#section-2.1.1>).

    My take is that with the root zone signed, the 4033 definition
    is obsolete, and the correct one is 4035.  This should probably
    be made explicit:

    4035 "indeterminate":

      An RRset for which the resolver is not able to determine whether
      the RRset should be signed, as the resolver is not able to obtain
      the necessary DNSSEC RRs.  This can occur when the security-aware
      resolver is not able to contact security-aware name servers for
      the relevant zones.

    4033 "indeterminate":

      There is no trust anchor that would indicate that a specific
      portion of the tree is secure.

Section 3.8, the text reads:

       The resolver attempted to perform DNSSEC validation, but a signature
       in the validation chain was expired.

   However, there are recent observations of domain where each RRset was
   accompanied by both expired *and* unexpired RRSIGs.

       https://twitter.com/VDukhovni/status/1171170411712827393

   So just *an* expired signature is not really a problem provided
   another signature for the same RRset is not expired.  So I think
   the text could more clearly read "but *all* signatures for an
   RRset in the validation chain expired", or some such.

Section 3.13: the text reads:

       The resolver attempted to perform DNSSEC validation, but the
       requested data was missing and a covering NSEC or NSEC3 was not
       provided.

   I think that "missing" can be misleading, it is not that the
   answer is "missing" from the response, but rather that the
   response affirmatively denies the existence of the requested
   RRset.  So perhaps "but the response denies the existence of
   the requested RRset" or something similar.

I find the two sections:

    3.16.  Extended DNS Error Code 15 - Blocked
    3.17.  Extended DNS Error Code 16 - Censored

somewhat confusing, it seems that the resolver returning the answer
is reporting second-hand status from an upstream server, but the
language leaves me unsure.  Perhaps this can be stated more clearly.

-- 
	Viktor.