> On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker <[email protected]> > wrote: > > Issue: > > The discussion of recursive resolvers in section 6.1 may need additional > consideration. In particular, the recommendation to pass a received error code > along to a client has, I think, some unintended consequences for the client. > If > the recursive server receives a NOTIMP, for example, passing that to the > client > tells the client the wrong thing about the server it is connected to. Perhaps > it would be better for the recursive server to return SERVFAIL in this > circumstance? (Similar to what it would do if it couldn't connect to the next > server as described at the bottom of page 10).
The only time NOTIMP is returned is in the case where DSO stateful operations (over which DNS PUSH runs) is not supported. This error code is due to the fact that DSO uses a different Opcode than the standard Query/Response Opcode. DSO defines a new opcode. The effect of this is that NOTIMP is the correct response if a server doesn’t support the new Opcode. Similarly, if DSO is supported but DNS Push TLV type is not supported, we return a new RCODE for DSO type not implemented DSOTYPENI. These are both required by existing specifications. If a client begins the connection with a DSO Keepalive to a resolver and the resolver accepts the connection, subsequent SUBSCRIBE operations that return NOTIMP will be obvious that the authoritative server does not support DSO. However, if the client begins with a SUBSCRIBE and receives NOTIMP from the resolver, it’s not clear if the NOTIMP was originated by the resolver or the authoritative server. Right now, we allow either DSO TLV to setup the state. In the case that the client begins with a SUBSCRIBE and the resolver returns NOTIMP, the client should attempt a connection with the authoritative server directly as described in 6.1. If the authoritative server returns NOTIMP, then PUSH notifications are not possible. While we could be more explicit about every error case, I don’t think the document says anything wrong here. Thanks, Tom _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
