On Jul 3, 2019, at 10:45 AM, Robert Sparks <rjspa...@nostrum.com> wrote: > And I think that's a problem. > > What does a NOTIMP mean to the client? Most of the draft says "The server > doesn't implement DSO". It doesn't say "doesn't implement DSO for this > particular set of bits in this query". Section 6.2.2 says the client should > assume a retry delay of 1 hour before talking to the server (the resolver) > again. > > Now, other parts of the document imply "for this particular set of bits" - in > the overview, near the bottom of page 5, it says to use NOTIMP (actually it > says NOTIMPL, maybe those are different things and I'm confused?) if a > message is received for a class other than "IN" and the server has only > implemented push for "IN". Again, that "assume a retry delay" kicks in.
Robert, first, thanks for doing a really thorough review of this document. This is much appreciated. This particular insight is one that I think is really important. I think your initial take on this is correct: if a resolver receives NOTIMP or DSONI from upstream, what this means is “fail,” not “not implemented,” from the perspective of the resolver. The resolver knows what the client is asking, and can’t do it. That’s SERVFAIL, not NOTIMP or DSONI. I think your subsequent point about terminating connections is also correct: we do not want a billion broken clients hammering on servers. However, the DSO document actually specifies how to deal with this: the server can tell the client to shut up for a period of time, and this is explicitly recommended for situations like this. The advantage of failing in cases like this is that it causes the implementation to not work, which then motivates the implementor to fix it. And thanks for the advice about how to terminate TLS connections—I had missed that nuance. Are TLS implementations actually able to do this (to reject RST packets)?
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
