Re: [DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02

[Matthew Pounsett <[e-mail]>]

On 14 July 2016 at 09:51, Ray Bellis <[e-mail]> wrote:

>
>
> On 12/07/2016 14:35, John Dickinson wrote:
> > You say that “ A caching recursive server receiving a Multiple QTYPE
> > Option SHOULD attempt to fill its positive and negative caches with
> > all of the specified RR types before returning its response to the
> > client.” won’t this run the risk of delaying a response to the
> > client?
>
> That's maybe a little strong - it could probably be weakened to "MAY".
>

I think one part of the value of this over ANY is that it is more clearly
specified that you can expect to get the records you requested.  If you
downgrade that SHOULD to a MAY, then I think it's reasonable to add a flag
for mandatory processing, so that a client can specify that it's willing to
wait for a complete answer to be compiled.


>
> > You say a server can “omit some (or all) of the records for the
> > additional RR types” in the case of truncation. Given the previous
> > quote, how should a caching recursive server behave in this case?
> > Query again for the missing QTYPES or switch to TCP?
>
> I think either would be acceptable.  The server shouldn't actually set
> the TC bot in those cases, so the client wouldn't be expected to
> automatically failover to TCP.
>

This was my understanding from reading the current text.  If more people
feel the expected behaviour is ambiguous then perhaps we can spell that out.