On Sep 11, 2019, at 9:50 PM, Wes Hardaker <[email protected]> wrote: > > Paul Hoffman <[email protected]> writes: > >> On Sep 11, 2019, at 4:02 PM, Wes Hardaker <[email protected]> wrote: >>> >>> Tim Wicinski <[email protected]> writes: >>> >>>> it sounds to me that a discussion on assumptions with EDEs and RCODES >>>> would be useful in the security considerations section as well. >>> >>> I'll look at wording along those lines. >>> >>> Note, however, that EDE codes are specifically meant as supplemental >>> information and shouldn't be "acted" upon. Hence >>> >>> Paul> A developer writes code that assumes that EDE X must go with RCODE Y >>> Paul> because the text for EDE X indicates that. The get a response with EDE >>> Paul> X and RCODE Z. The code rejects that, and does not act on RCODE Z. >>> >>> "does not act on RCODE Z" is already the right approach, since it's >>> unauthenticated in the first place (which is discussed in the >>> document). >> >> I do not understand this. Many receivers of RCODEs act on them even >> though they are unauthenticated. A recursive resolver receiving a >> message with RCODE of SERVFAIL will look at other authoritative >> servers, for example. > > You implied said ""RCODE Z" but implied "RCODE Z but also looked at EDE > code X", and deliberately didn't act on Z because the presence of EDE > code X. This document isn't (and shouldn't) change the processing > behavior of RCODEs; it only augments an additional message with > additional information which can be reported to the user or log or ... > It's not supposed to affect decision processing.
But that sentence doesn't appear anywhere in the document. Proposal: add the following sentence to the end of the abstract: "Extended error information does not change the processing of RCODEs." Proposal: add to the end of the Introduction: Applications MUST NOT change the processing of RCODEs in messages based on extended error codes. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
