What if stream and request-ID are in conflict? about dnsoquic HOT 5 CLOSED

We need to consider the effect of RST-STREAM. Any of the parties can reset a stream at any time. We assume that this will cause the transaction to be abandoned: SERVFAIL if the server resets the stream, some client action if the client gives up on the transaction before it is fully complete. Having responses come on a different stream would not play well with that at all.

Proposal: clients shall verify that the query-id in the response matches the query-id that they sent in the query. If it doesn't, they should do something. But what? Probably too late to reset the stream, since it is now closed by both ends...

from dnsoquic.

On the first one: This is a "DNS over QUIC" protocol error, which IMO should cause the client to discard responses and close the QUIC connection. The client should also mark the server as "broken" for future use of DNS over QUIC.

from dnsoquic.

In terms of matching section 6.4 already proposes using the same text as RFC7766 that clients MUST match on the QNAME, QCLASS, and QTYPE fields on a given stream. As for what to do if the match doesn't happen I think I agree with Jana that this is a bad enough error to back-off from the server.

from dnsoquic.

Resolution: doq should use zero.

from dnsoquic.

Specified in Dprive draft.

from dnsoquic.