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! _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
