On Sep 10, 2019, at 4:02 PM, Wes Hardaker <wjh...@hardakers.net> wrote: > > Paul Hoffman <paul.hoff...@icann.org> writes: > >> 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. > > I think that works. I extended it with one more sentence: > > <t>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. Receives MUST be able to accept > EDE codes and text in all messages, including even those with a > NOERROR RCODE.</t>
Thanks. However, I still think this opens a lot of security holes if developers try to be "smart" by assuming that some EDEs only make sense with some RCODEs. If I'm in the rough, I'll be quiet. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
