On Sep 9, 2019, at 9:05 PM, Wes Hardaker <wjh...@hardakers.net> wrote: > > Paul Hoffman <paul.hoff...@icann.org> writes: > > Hi Paul, > > Thanks for the comments and good suggestions. Responses below inside my > todo list of action: > > 12 Paul Hoffman > =============== > > Greetings again. The changes here generally help the document, but > they also highlight some of the deficiencies. A few comments on the > current draft: > > > 12.1 NOCHANGE what error codes? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - The spec does not say anything about the kinds of responses where it > is allowed to send particular extended error codes. For example, if a > response has an RCODE of NOERROR, what does it mean for it to also > have a EDE? Or if the RCODE is FORMERR, can it have an EDE that > relates to DNSSEC validation failure? The exact semantics for the > receiver need to be specified. > > + The EDE was specifically meant to be an "addition" to an existing > reply of *any* RCODE, including NOERROR codes. There is no > restriction about when you might include one. Similarly, it makes > no sense for some codes to be returned for some RCODES, but any good > receiver shouldn't segfault either. I don't think we can specify > all potential combinations in any meaningful way.
Being silent on this is also bad. Proposed text for the introduction: 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. Having said that, I think not having restrictions on which EDE can be used with which RCODE with systems in particular roles is actively dangerous. We know that software developers *will* make such assumptions, and attackers will use those wrong assumptions in the future. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
