On 12/07/2016 14:35, John Dickinson wrote: > 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?
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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
