Re: [DNSOP] New Version Notification for draft-bellis-dnsext-multi-qtypes-03.txt

[Ray Bellis <[e-mail]>]

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