On 2.8.2017 16:56, Edward Lewis wrote: > On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" <dnsop-boun...@ietf.org on > behalf of sh...@time-travellers.org> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
