[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-extended-error-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sections 4.16 and 4.17 have some discussion that suggests that the
respective extended errors apply only to the current "local hop" of a DNS
query, and thus should not be propagated by a resolver/forwarder as part of
a response.  If so, this would be at odds with the discussion in Section 3
that leaves such bhavior as merely "implementation dependent" (giving some
MAY-level options).  I'm not sure what the intent is, here, so let's talk
about whether there's anything that should change.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.16

   The server is unable to respond to the request because the domain is
   blacklisted due to an internal security policy imposed by the
   operator of the server being directly talked to.

This wording implies that code 15 MUST NOT be copied by a
resolver/forwarder, which is somewhat at odds with Section 3.

Section 4.17

   The server is unable to respond to the request because the domain is
   blacklisted by a security policy imposed upon the server being talked
   to by an external requirement.  Note that how the imposed policy is

[ditto]

COMMENT

The RFC Editor is going to have to look closely at a lot of commas, but I'll
try to not dwell too much on them here.  I will note that "i.e." and "e.g."
are to be offset from other text both before and after, whether by comma,
parenthesis, dash, or other punctuation.

Section 1

   A good example of issues that would benefit by additional error
   information are errors caused by DNSSEC validation issues.  When a
   stub resolver queries a name which is DNSSEC bogus (using a

I know that "DNSSEC bogus" is a term of art, but not everyone will.  Would a
reference to RFC 8499 somewhere in here be worthwhile?

   option is to ask the next configured DNS resolver.  The result of
   trying the next resolver is one of two outcomes: either the next
   resolver also validates, and a SERVFAIL is returned again or the next
   resolver is not a validating resolver, and the user is returned a
   potentially harmful result.  With an Extended DNS Error (EDE) option

nit: some puncuation before "or the next resolver is also", please.

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

It's not really clear what actionable guidance there is in "MUST NOT assume
that [...] will make sense".

Section 1.1

Please use the current BCP 14 boilerplate from RFC 8174.

Section 2

      message.  The INFO-CODE serves as an index into the "Extended DNS
      Errors" registry Section 5.1.

nit: maybe "registry defined in"?

   o  EXTRA-TEXT, a variable length, UTF-8 encoded, text field that may
      hold additional textual information.  Note: EXTRA-TEXT may be zero
      octets in length, indicating there is no EXTRA-TEXT included.
      Care should be taken not to leak private information that an
      observer would not otherwise have access to, such as account
      numbers.

What's the internationalization plan for EXTRA-TEXT?  (See BCP 18.)
(Also, I'm apparently not imaginative enough to come up with a case where an
account number would be in an error message, so I am glad that you thought
of it and included it!)

Section 3

   supplemental nature of EDE.  Implementers and operators creating EDE
   options SHOULD avoid setting unnecessarily long EXTRA-TEXT contents
   to avoid truncation.

nit(?): "SHOULD avoid setting unnecessarily long" is not clearly actionable;
perhaps "should be mindful of such potential consequences of long EXTRA-TEXT
contents when generating EDE information" is better?

   When a resolver or forwarder receives an EDE option, whether or not
   (and how) to pass along EDE information on to their original client
   is implementation dependent.  Implementations MAY choose to not
   forward information, or they MAY choose to create a new EDE option(s)
   that conveys the information encoded in the received EDE.  When doing

Just to check: they can only create new EDE options if the relevant OPT
pseudo-RR was in the query from the client?  (I guess we don't say anything
about the resolver or forwarder adding such an option to its outbound query,
so maybe this is implicit.)

Section 4.4

Is a reference to RFC 8767 appropriate for "serve-stale"?

Section 4.8, 4.9

(Just to check: it is okay/conceivable to return both codes 7 and 8 for the
same response?)

Also, s/but but/but/

Setion 4.13

[I guess NSEC5 isn't happening, so we don't need to be future-proof for it?]

Section 4.21

   response.  A resolver that receives a query (with the RD bit clear)
   SHOULD include this EDE code in the REFUSED response.

It seems like it would be appropriate to remove the parentheses here.

Section 4.2

side note: it's a little surprising to see a "not supported" code be
described as specifically due to deprecation, to the exclusion of "not yet
supported".

Section 5.1

   Value  Name                 Status    Reference
   -----  ----------------     ------    ------------------
    TBD   Extended DNS Error    TBD       [ This document ]

Shouldn't we say what "Status" we're requesting?

Section 5.2

   INFO-CODE:  0
   Purpose:  Other Error

Just to note: the Section 4.1 heading is just "Other", not "Other Error".

   INFO-CODE:  3
   Purpose:  Stale Answer
   Reference:  Section 4.4, [I-D.ietf-dnsop-serve-stale]

(That's RFC 8767 now.)

   INFO-CODE:  14
   Purpose:  Not Ready.
   Reference:  Section 4.15

nit: none of the other entries have a full stop.

   INFO-CODE:  19
   Purpose:  Stale NXDomain Answer
   Reference:  Section 4.20

nit: should "NXDOMAIN" be in all-caps?

Section 6

   Though DNSSEC continues to be deployed, unfortunately a significant
   number of clients (~11% according to [GeoffValidation]) that receive
   a SERVFAIL from a validating resolver because of a DNSSEC validaion
   issue will simply ask the next (potentially non-validating) resolver
   in their list, and thus don't get any of the protections which DNSSEC
   should provide.

"Don't get any of the protections" is a very strong statement, which is
arguably too strong, here.  Maybe just "don't get the reliability of
protection that DNSSEC should provide"?

Is the intent that allowing EDE to be attached to SERVFAIL will reduce the
occurrence of this "blindly proceed to the next (potentially non-validating)
resolver" behavior?  If so, we should say that!

   This information is unauthenticated information, and an attacker (e.g

I'm not actually sure which information "this information" is intended to
refer to.  At first I thought the SERVFAIL from the previous paragraph, but
this seems to be talking about a more generic issue (and neither does it
seem to be the EDE we're introducing in this document, since the sentence
ends "could insert an extended error response" as if that's in addition to
"this information").  Please clarify!