> On Jul 3, 2019, at 11:12 AM, Ted Lemon <[email protected]> wrote: > > On Jul 3, 2019, at 10:45 AM, Robert Sparks <[email protected] > <mailto:[email protected]>> 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. >
a. If the client sends SUBSCRIBE or KEEPALIVE to the resolver and the resolver doesn’t support DSO, it will send NOTIMP whether you want it to or not because it doesn’t know about the opcode. b. If the client sends SUBSCRIBE and gets back DSONI from the resolver because it supports DSO but not PUSH Notifications, the resolver is following the DSO spec. c. If the client sends KEEPALIVE and successfully establishes a DSO connection to the resolver and then sends SUBSCRIBE and the resolver gets back NOTIMP from the authoritative, and returns this to the client, then the client knows exactly that the problem is that the authoritative doesn’t support DSO. To solve the ambiguity: 1. The client should only send SUBSCRIBE to set up the DSO session if it has gone through the discovery process and wants to talk to the authoritative directly. If it wants to try to subscribe to push notifications through a resolver, then it should use KEEPALIVE first to establish the DSO connection with the resolver. 2. If the resolver supports SUBSCRIBE but the authoritative doesn’t, the resolver should not send DSONI back to the client because the client can’t tell the difference between the resolver not supporting SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In this case, the resolver should return SERVFAIL. This should inform the client that the authoritative doesn’t support SUBSCRIBE. If there are multiple authoritative servers supporting _dns-push._tcp, the resolver may want to try all of them before returning SERVFAIL. > 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)? This was actually a comment from David Schinazi (and a good one). I’ve adjusted the working copy on github but there’s still one section I’m wrestling with regarding TCP RST. Thanks, Tom
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
