On 18 Aug 2016, at 8:04, Matthew Pounsett wrote:
On 18 August 2016 at 10:40, Paul Hoffman <paul.hoff...@vpnc.org>
wrote:
Are there QTYPEs that, when I ask for them, I won't know that I
should
also ask for the related info?
Probably not. However, there may be owner names you don't know you
need to
ask for. In the example of SRV, the owner name of the original query
won't ever match the owner name of hosts in the RDATA, so simply
asking for
extra QTYPEs in a pull is insufficient.
Maybe you have walked down a solution path too far. A pull for SRV might
indeed allow any A/AAAA records for hosts in the RDATA.
Also take for example the transition from not having HTTP SRV to
having
it. One of the arguments against from the browser developer community
is
the additional round trips. One of those extra round trips is the
need to
request both the A/AAAA of the requested host and the
_http._tcp.<apex> SRV
record in separate queries, not knowing if the latter even exists. A
server that can supply the latter (and related records from the RDATA)
with
the former nullifies that argument against implementation.
Indeed it does, and that sounds sensible if the client asked for
SRV-related info.
Remember that in the proposals we've been discussing, a PUSH still
requires
that the client signal its ability to deal with pushed data. That
means
that the only functional difference between a PUSH and a PULL is who
decides which extra data is supplied. It's my assertion that the
server
is always going to be in a better position than the client to know
when
there's necessary or useful additional data.
And it is my opinion that some pushers will use that both for good, and
then for spam. I see no reason to open the door to the second.
Hrm. Or maybe we can.
A different idea: a pull option that says "send me whatever the heck you
want related to this QNAME", that would likely never be used by stubs,
but could be used by interested recursive resolvers that feel like they
have plenty of cache available and want to give faster answers to their
clients.
--Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
