Paul Hoffman <paul.hoff...@icann.org> writes: > On Sep 11, 2019, at 4:02 PM, Wes Hardaker <wjh...@hardakers.net> wrote: > > > > Tim Wicinski <tjw.i...@gmail.com> 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. [arguably with the R bit in place, it was; but we removed that] -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
