On 03/11/2016 17:57, Wessels, Duane wrote: > 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 would take that to be any RR in the ranges set aside for meta types in the IANA RRTYPE registry, plus OPT. > I don't think the document says how a server should respond to > receiving a forbidden pseudo type, does it? I think you're right. Do you think it should be FORMERR, or perhaps just ignore any disallowed types [and omit them from the returned QTn list] ? >> 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? My gut reaction is the latter, on the basis that this is closest to "fallback to non-supporting behaviour". I'm not sure there's a definitive correct answer, though. >> 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... :-) Yes, AIUI in theory you'd get individual RRSIGs over the QTn records that exist, and a single NSEC[3] record that proves the existence (or otherwise) of any others. FWIW, I don't intend to spend too much more time on this draft until such time as DNSOP determines that this really is a problem worth solving. thanks for the review! Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
