[dnssd] multi-qtypes - possible updates

[Ray Bellis <[e-mail]>]

Hey folks,

Here's a summary of various suggestions made in the last couple of 
months, some of which were either off-list or in the DNSOP WG.  Most of 
these warrant additional discussion here before any significant changes 
get made to the text.

## Use of NSEC bitmaps instead of a list

Paul Wouters argued strongly for this on DNSOP, but got little support.

This also came up in historic discussions of the draft and was argued 
against on the basis that NSEC bitmaps are inefficient for sparse sets 
of RRTYPEs.  Quoting Vixie - "noone should be using that bitmap as an 
example of how to do other things".

Proposal: no further action

## Meta RRs (Offlist from Stuart):

 > Can we add some explicit text about how to handle “special” RRtypes
 > if they appear in a multi-qtypes EDNS option, such as:
 >
 > OPT  (RR type  41)
 > TSIG (RR type 250)
 > ANY  (RR type 255)
 >
 > E.g., a sender MUST NOT include these special RRtypes; if they are
 > received then the receiver MUST silently ignore them? Not include
 > them in the returned multi-qtypes EDNS option? Return FORMERR?
 > (Don’t particularly care which, but we should say.)

The draft already had a requirement to exclude these types.  I've added 
text in my working copy that says to return FORMERR.

## QTD and QTCOUNT fields (also offlist from Stuart)

 > Having the redundant QTCOUNT field worries me. If QTCOUNT field is
 > larger than OPTION-LENGTH requires, then we risk buffer overrun bugs.
 > If QTCOUNT field is smaller than OPTION-LENGTH requires, then there
 > is hidden data lurking at the end of the option, and such hidden data
 > can have security problems if different components (e.g., a firewall
 > and the end system) treat it differently.

My personal view is that these classes of bugs are already well known to 
authors of DNS parsers which routinely have to deal with under-filled or 
over-filled buffers.  If the existing encoding is retained then text 
requiring a FORMERR in these circumstances would be a good idea.

Proposal: more discussion required

 > Instead of the QTD flag, I would use two OPTION-CODEs. They are not
 > in short supply. One OPTION-CODE for the outgoing request, a
 > different one for the returning response.
I've used the paired OPTION-CODE method myself in another draft, but 
this is slightly wrapped up with the QTCOUNT discussion above, since the 
QTD and QTCOUNT fields share the same octet.

Proposal: more discussion required

## QTCOUNT limits

If QTCOUNT is removed should the I-D specify an arbitrary limit on the 
number of QTYPEs beyond which FORMERR is returned?  Part of the 
rationale for QTCOUNT is to mitigate the risk of this specification 
being used for DNS amplification attacks.

If we do want a limit is 7 the correct number?  Would e.g. 3 suffice for 
any envisaged use case?

Proposal: more discussion required

## Use specific bits for popular QTYPEs

Esko Dijk proposed an alternative scheme with reserved bits for TXT, A, 
etc.  No-one followed this up.

Proposal: No further action

## AA bit handling

I've known for a while that the I-D needs text to address queries for 
records that might fall either side of a zone cut and therefore have 
different AA bits.  The text that talks about being "authoritative for 
the specified QNAME" is incorrect because it also depends on the QTYPE 
(e.g. in the case of DS records)

If I've missed anyone please let me know!

Chris - you said you had some ideas but I don't think you've written 
them down anywhere?

Ray