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

From: "John Dickinson" <[email-masked]>
Date: Tue, 12 Jul 2016 14:35:09 +0100

Hi,

I think that a bit more should be said on the problem statement in the introduction.

I might have missed it, but what entity originates the query? Stub or resolver?

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?

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 am also wondering how this interacts with https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-03?

regards
John

John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 14 Jul 2016 14:51:49 +0100

> I might have missed it, but what entity originates the query? Stub or

It's suitable for both.  It could perhaps benefit from being spelled out
more explicitly.

> 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".

> 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.

> I am also wondering how this interacts with
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-03?

I've no idea (yet) - that didn't exist when I wrote it :p

Ray

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 14 Jul 2016 13:03:19 -0400

> 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.

> 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.