On 7/2/19 4:24 PM, Tom Pusateri wrote:
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.
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.
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.
But there's fate sharing, at least as I'm reading the document now. That
resolver could have been authoritative (or could reach an authoritative
server) for some other subscription. But you've told the client that
it's not ok to talk to this resolver for any subscription (for an hour
at least).
While we could be more explicit about every error case, I don’t think the
document says anything wrong here.
And I used NOTIMP as an example. I think there may be fate sharing
issues with other response codes as well.
Thanks,
Tom
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
