[DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error

[Edward Lewis <[e-mail]>]

On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" <[e-mail] on behalf of [e-mail]> wrote:

>...
>I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? 

If a receiver can't trust what it gets from the network, you can't run a protocol.  Dead in the water.

No matter what, what a receiver does next will depend on what it gets from the network (or doesn't get/timeout).  That happens now, in an unmanaged way.  IMHO, it would be good to address that (the reactions, as opposed to elaborating on the error).

If you are worried about having trustable error codes, think of a way to secure the channel (like TSIG).  If you are worried and can't secure the channel, then it doesn't matter whether RCODES are extended or not - you have nothing trustable to act upon.  (See: dead in the water.)

Once you have faith that there's usefulness in the error/response code you do receive, then you can design what the reaction is.  (If you are worried, you need to do what is necessary to build the faith or this will not be solvable.)

I sent a long message urging that the response indicate the next step, not so much indicating what went bad.  I won't belabor that - my motivation comes from the observation that many folks are used to "debugging" DNS via query/resposnse as they are not the authorized operator of the answering system.  Extending RCODEs should be about solving the protocol's needs, not about preserving the ability of remote debugging of servers, leave that to the authorized operator.