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

["Wessels, Duane" <[e-mail]>]

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