Hi Shane, On Jul 29, 2017, at 09:05, Shane Kerr <sh...@time-travellers.org> wrote:
> I guess that I understand your concern, but we don't have any way to > authenticate servers in DNS today and we already send error messages back. > > 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? In the case of validation failures, today a DNS client (of whatever kind) can receive a SERVFAIL of unknown authenticity from a resolver and has to do more work to figure out what that means. It can't just assume that there has been a validation failure upstream. Ultimately it can re-fetch records with CD=1 and do its own validation if it needs to understand the reason for the failure in detail. The motivation for extended RCODEs is to be able to provide more fine-grained indiciations to a client than are currently provided. In the case of a conventional SERVFAIL response, for example, the client might also receive some information that further indicates that the reason for the SERVFAIL was an upstream validation failure. It feels like there is more potential in this second case for a client to believe what it was told and avoid further checking (this is an example of your "change client behaviour"). Without an authenticated response, should we not be concerned about the threat that a bogus response from a third party system might mask an otherwise legitimate and positive response? If client behaviour is not supposed to change when you return an extended RCODE, why bother returning one? I'm not saying this particular threat is credible or high-probability necessarily, but it seems sensible to think about this with a little more energy than "it's no worse than what we have today". Maybe the answer is to say "don't use this mechanism to indicate validation failures". Maybe there's a different approach that could accommodate signed extended responses, and writing that up from scratch is more sensible than adapting what's currently on the table. I'm not presupposing the answer, just thinking aloud. I don't have a strong opinion about it, but it does seem reasonable to consider these kinds of things before assuming that any particular draft fits the requirements and should be adopted. Nothing against Warren's fine draftsmanship, of course! Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
