Hi Ray,
> QTn: a 2 byte field (MSB first) specifying a DNS RR type. The RR > type MUST be for a real resource record, and MUST NOT refer to a > pseudo RR type such as "OPT", "IXFR", "TSIG", "*", etc. How is an implementation expected to know which types are pseudo? Should this document specify the list of forbidden pseudo types at the time of publication? I don't think the document says how a server should respond to receiving a forbidden pseudo type, does it? > A server that is authoritative for the specified QNAME on receipt of > a Multiple QTYPE Option MUST attempt to return all specified RR types > except where that would result in truncation in which case it may > omit some (or all) of the records for the additional RR types. Those > RR types MUST then also be omitted from the Multiple QTYPE Option in > the response. Data in the Additional section also competes for space up to the truncation limit, right? Which has priority, the Multiple QTYPE data or the normal Additional data? > If the DNS client sets the "DNSSEC OK" (DO) bit in the query then the > server MUST also return the related DNSSEC records that would have > been returned in a standalone query for the same QTYPE. > > A negative answer from a signed zone MUST contain the appropriate > authenticated denial of existence records, per [RFC4034] and > [RFC5155]. So we should expect to see single responses that have both positive and negative DNSSEC records together. That should be fun... :-) DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
