I'm not seeing the place in RFC 1034 where it explicitly specifics any value at all for QDCOUNT. Can you point to it?
Note that if we think of this in terms of trying to understand what the writers intended, then your conclusion might make sense, but that's not good enough. It needs to actually unequivocally say what to do and what not to do, or else anything that is within the bounds of what is said is something that is actually said is valid to do. Certainly multiple questions is within the bounds of what is said, even if you think it is meaningless to have more than one. On Wed, Feb 15, 2023 at 8:13 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Joe Abley wrote: > > > I'm not convinced that 1034/5 really allow QDCOUNT > 1, > > 1034 specifies standard queries and responses must have > QDCOUNT=1 but 1035 explicitely allows responses to > inverse queries have QDCOUNT>1. Inverse queries must > have QDCOUNT=0. > > > even if they left that door temptingly open. But we know that > those > are old documents that lack normative clarity. > > In this case, quite normatively, 1034 states: > > Of the possible 16 values, > one (standard query) is part of the official protocol, two (inverse > query and status query) are options, one (completion) is obsolete, and > the rest are unassigned. > > but status query is not specified. > > So, there is no specification to mention queries with QDCOUNT>1, > either informatively, optionaly or normatively. > > Then, 3425 titled "Obsoleting IQUERY" updated 1035. > > As such, after 3425, QDCOUNT nomatively must always be 1. > > > It will be interesting to find out whether using QDCOUNT > 1 > > in practice is useful. > > Meaninglessness of queries matching multiple RR types > is already documented by 1035. See my first mail of the > thread. > > Masataka Ohta > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
