Additionally it was predicated on caches not having the concept
of a negative cache
"The difficulty is that the presence of one
RR type in a cache doesn't convey any information about the other
because the query which acquired the cached information might have used
a QTYPE of MF, MD, or MAILA (which matched both).”
We have negative caches today. It’s also not like we don’t know how to
signal that QDCOUNT > 1 is not supported (return FORMERR) or signal that
it is supported (e.g. EDNS=1). The hardest thing is the broken servers
that don’t return FORMERR correctly making it hard to determine what they
actually support. Clients can retry with individual queries if they get
FORMERR returned.
The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn’t prohibit other values.
"4.1.2. Question section format
The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked. The section
contains QDCOUNT (usually 1) entries, each of the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
QNAME a domain name represented as a sequence of labels, where
each label consists of a length octet followed by that
number of octets. The domain name terminates with the
zero length octet for the null label of the root. Note
that this field may be an odd number of octets; no
padding is used.
QTYPE a two octet code which specifies the type of the query.
The values for this field include all codes valid for a
TYPE field, together with some more general codes which
can match more than one type of RR.
QCLASS a two octet code that specifies the class of the query.
For example, the QCLASS field is IN for the Internet."
> On 16 Feb 2023, at 14:08, Ted Lemon <mel...@fugue.com> wrote:
>
> Again, it does not say that explicitly. Your interpretation is valid but not
> the only possible reading of the test you quoted. It’s certainly not how I
> read it.
>
> On Wed, 15 Feb 2023 at 20:33, Masataka Ohta
> <mo...@necom830.hpcl.titech.ac.jp> wrote:
> Ted Lemon wrote:
>
> > I'm not seeing the place in RFC 1034 where it explicitly specifics any
> > value at all for QDCOUNT. Can you point to it?
>
> See my second mail of the thread.
>
> Masataka Ohta
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
