On Oct 21, 2021, at 7:07 AM, Sara Dickinson <[email protected]> wrote: > > > >> On 21 Oct 2021, at 00:16, Paul Hoffman <[email protected]> wrote: >> >> After reading the -06 somewhat carefully, I have only one question: why >> should the DNS message ID be set to 0? If there's a good reason, is should >> be listed in Section 5.2.1, but if there isn't, the requirement should be >> removed. As the text indicates, this requirement makes forwarding more >> difficult. It also makes a special case for a client implementation that can >> do both DoQ and DoT. > > Hi Paul, > > The stream mapping of DoQ allows for unambiguous correlation or queries and > responses so the the message ID isn’t needed. Using 0 means the number of > outstanding queries on a DoQ connection isn’t limited to the Message ID space > which would be an artificial limit inherited from DNS-over-UPD/TCP. It seems > wrong to impose that on a transport specifically designed to multiplex, just > to make proxying simpler. Given that RFC8484 says "DoH clients ... SHOULD > use a DNS ID of 0 in every DNS request.” that proxy problem already exists > and isn’t unique to DoQ.
Arrrgh. I vaguely remembered that discussion. I forgot that we ended up with that in DoH, so it's OK if we end up with it in DoQ. > It’s presence would also change the error condition from ‘what if the message > ID isn’t 0’ to 'what happens if the response ID on a stream doesn’t match the > query ID?’. It’s marginal but the former feels slightly cleaner. We disagree on which feels cleaner, but that's moot. My argument against always-0 (it differs from DoT) is trumped by it being the same as DoH. This is a hassle that implementers have already seen. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
