Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Wes Hardaker <[e-mail]>]

Paul Hoffman <[e-mail]> writes:

> On Sep 11, 2019, at 4:02 PM, Wes Hardaker <[e-mail]> wrote:
> > 
> > Tim Wicinski <[e-mail]> 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