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

From: [email-masked]
Date: Tue, 10 Sep 2019 20:45:36 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Extended DNS Errors
        Authors         : Warren Kumari
                          Evan Hunt
                          Roy Arends
                          Wes Hardaker
                          David C Lawrence
	Filename        : draft-ietf-dnsop-extended-error-09.txt
	Pages           : 13
	Date            : 2019-09-10

Abstract:
   This document defines an extensible method to return additional
   information about the cause of DNS errors.  Though created primarily
   to extend SERVFAIL to provide additional information about the cause
   of DNS and DNSSEC failures, the Extended DNS Errors option defined in
   this document allows all response types to contain extended error
   information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-09
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Sep 2019 02:05:29 -0400

> 	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.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 16:44:15 -0700

Viktor Dukhovni <[email-masked]> writes:

Thanks Viktor,

Thanks for the comments.  Responses are inline below in my tracking
notes below.

14.1 DONE Viktor Dukhovni
~~~~~~~~~~~~~~~~~~~~~~~~~~~

14.1.1 DONE 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.. [...]

14.1.2 DONE 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.

  + Response: there seems to be consensus around this and I adopted
    Paul's text to clarify this

14.1.3 DONE 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.

14.1.4 DONE 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.

14.1.5 NOCHANGE account numbers and privacy
-------------------------------------------

  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.

  + Response: I agree, it's a bit of an unusual statement.  But it was
    suggested by Shane Kerr in the summer and if you want to suggest
    better text for replacing it, I need a real suggestion as deleting
    it would delete his desire to have an example in there (which I
    agree with, FWIW).  Maybe "account name" would be a middle ground?

14.1.6 DONE 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.

  + Vladimír Čunát adds

    I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
    algorithms being unsupported, and it actually makes me wonder how to
    exactly write the resolver code that would set this pair.  For
    validation I need at least one usable DS RR, i.e. one where *both*
    the DS and DNSKEY algorithms are supported.  I believe that's the
    exact condition to be able to extend the trust chain. (and that's
    how I implemented it for Knot Resolver)  It may theoretically even
    happen that there is a supported DS algorithm and a supported DNSKEY
    algorithm but never paired together in the DS RRset - IIRC it's not
    perfectly correct to generate such an RRset but that's probably not
    something a validator should care for.

  + Response: Error 1 (unsupported DNSKEY alg) could be included in any
    message where the DNSKEY algorithm (say 1 RSA/MD5) isn't
    supported. A servfail would be returned with EDE-1 as well.

    For DS unsupported, a similar case occurs when chaining from the
    parent and a DS Digest Type of 1 (MD5) is hit that the validator
    doesn't support.  I *think* the problem is that the text should
    really say "Unsupported DS Digest Type", which I'll go change it to.
    Let me know if that's wrong.

14.1.7 DONE 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.

  + Response: good point.  I'll use a reference to 4035.

14.1.8 DONE Section 3.8, the text reads:
----------------------------------------

  [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.

  + Response: good point, changed

  + Vladimír Čunát adds

  Nitpick: *if* we were diving into such details... each RRSIG might
  fail for a different reason, for example.  That's the general problem
  with providing reasons for validation failures: validation is defined
  in the sense that you (may) succeed when at least one of various ways
  succeeds.  A failure could typically be fixed by multiple different
  ways (EDE codes).  Still, I'd hope that in most real-life cases the
  implementations can "correctly" guess what's wrong.

  + Response: That's true, and I think if you had sigs that were both
    "early" and "late" but not "now" you'd return both codes or more
    likely an "other" error code (0) with informational text.

14.1.9 NOCHANGE 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 think you're misreading that section (or I'm not following).  The
    point is that the validator *failed* to get a NSEC or NSEC3 that
    proved the name doesn't exist to match the NXDOMAIN.  So the
    validator changed all the way down through keys and then got an
    NXDOMAIN with no NSEC for 'wwww'.

14.1.10 DONE 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.

  + Response: Those three codes were supplied in a previous comment
    round and they are supposed to indicate policies being applied from
    different sources.  Can you check the new text of them to see if
    they are more understandable now?

-- 
Wes Hardaker
USC/ISI