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

[Petr Špaček <[e-mail]>]

On 2.8.2017 16:56, Edward Lewis wrote:
> 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.

I very much agree with Edward!

To be more specific, I think we should aim for set of information which
helps the user to to decide who to contact:

a) contact local support / fix his local system
(e.g. system time is likely off and validation fails for this reason)

b) contact ISP support
(e.g. local forwading cache is not able to contact recursor)

c) contact domain owner, e.g. bank
(e.g. all the NSes are timing out)

-- 
Petr Špaček  @  CZ.NIC